tbnl-devel

tbnl-devel@common-lisp.net

865 discussions

Re: [hunchentoot-devel] easy-handler outputs to REPL instead of client
by Tyler Smith 23 Dec '11

23 Dec '11

On Thu, Dec 22, 2011 at 6:18 PM, Jens Teich <info(a)jensteich.de> wrote: >> (define-easy-handler (tyler :uri "/tyler") () >> (multiple-value-bind (records fields) >> (select [genus] [species] :from "specimens") >> (loop for rec in records do >> (loop for label in fields >> for val in rec do >> (with-html-output (*standard-output*) >> (:dt :class label (str label)) >> (:dd :class label (str val))))))) > > use with-html-output-to-string > with-html-output-to-string produces no output, either to the REPL or to the browser. Entering just the (M-V-B ...) expression (i.e., removing the define-easy-handler form) at the REPL also produces no output using W-H-O-to-string. Cheers, Tyler

1 0

[hunchentoot-devel] log files
by Haris Bogdanovich 21 Dec '11

21 Dec '11

Hi. I forgot, how do I set error log and access log files ? Thanks

4 8

[hunchentoot-devel] #handlers section missing from the documentation
by Vladimir Sedach 13 Dec '11

13 Dec '11

Hello, There are several places in the documentation that reference the "handlers" section (as #handlers), but there's no longer a subchapter with that name. Vladimir

2 1

[hunchentoot-devel] Subclassing ACCEPTOR
by Sebastian Tennant 12 Dec '11

12 Dec '11

Hi list, (make-package :vhost :use '(:common-lisp)) ;;; => #<PACKAGE "VHOST"> (in-package :vhost) (defclass vhost (tbnl:acceptor) ((tbnl::name :initform (error "Please give this VHOST a meaningful name.")))) ;;; => #<STANDARD-CLASS VHOST> (describe 'vhost) ;;; => VHOST::VHOST ;;; [symbol] ;;; ;;; VHOST names the standard-class #<STANDARD-CLASS VHOST>: ;;; Class precedence-list: VHOST, HUNCHENTOOT:ACCEPTOR, STANDARD-OBJECT, ;;; SB-PCL::SLOT-OBJECT, T ;;; Direct superclasses: HUNCHENTOOT:ACCEPTOR ;;; No subclasses. ;;; Direct slots: ;;; HUNCHENTOOT::NAME ;;; Initform: (ERROR "A virtual host must have a meaningful name.") (defvar *vhost1* (make-instance 'vhost)) ;;; => *VHOST1* <--- WHY NO ERROR ??? (describe *vhost1*) ;;; => #<VHOST (host *, port 80)> ;;; [standard-object] ;;; ;;; Slots with :INSTANCE allocation: ;;; PORT = 80 ;;; ADDRESS = NIL ;;; NAME = #:G1150 <--- this is what I want to prevent ;;; [...] Practical Common Lisp - page 214: "... if multiple classes specify an initform the new class uses the one from the most specific class. This allows a subclass to specify a different default value than the one it would otherwise inherit." What am I doing wrong here? Sebastian -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap

2 3

[hunchentoot-devel] patch for fixing abort-request-handler's use of handler-done tag
by Gordon Sims 07 Dec '11

07 Dec '11

Here's a patch that changes abort-request-handler's use of handler-done tag to be consistent with the catch of it (and also consistent with the throw in handle-request). Before this patch is applied, using abort-request-handler causes this response, note there is no error message or backtrace. <html> <head> <title>Internal Server Error</title> </head> <body> <h1>Internal Server Error</h1> An error occured while processing your /stat/config/monitor.debug.eval.enabled request. <hr/> <h1>Error Message</h1> <pre>ERROR</pre> <h1>Backtrace</h1> <pre>BACKTRACE</pre> <hr/> <a href="http://weitz.de/hunchentoot">Hunchentoot</a> 1.2.0 running on Clozure Common Lisp Version 1.7-r15010M (LinuxX8664) <hr/> <img src="/img/made-with-lisp-logo.jpg" width="300" height="100"/> </body> </html> After patch applied, error message and backtrace appear in the HTTP 500 response. -Gordon

1 0

[hunchentoot-devel] Help needed with changes since 1.1
by PL Hayes 02 Dec '11

02 Dec '11

Hi. My *extremely* simple website won't work with 1.2.1. and I've no idea why. All it consists of is this: (push (hunchentoot:create-folder-dispatcher-and-handler "/misc/" #p"/home/plh/misc-web/") hunchentoot:*dispatch-table*) but I just get the 'not found' error page when I try to visit any of the files in that directory.

2 4

[hunchentoot-devel] Hunchentoot release 1.2.2
by Hans Hübner 30 Nov '11

30 Nov '11

Hi, I made a new release of Hunchentoot today. It is a minor release that mainly corrects documentation errors. Here is the CHANGELOG excerpt: Fix warning on LispWorks (Nico de Jager) Documentation updates Remove obsolete symbols from export list Add easy-ssl-acceptor Document acceptor-remove-session, remove obsolete *session-removal-hook* export (Issue #15) Added :description to asdf system definition Add documentation section describing how to bind to privileged ports The tarball is available here: https://github.com/downloads/edicl/hunchentoot/hunchentoot-1.2.2.tar.gz Please let me know if there are any issues. Thanks, Hans

1 0

[hunchentoot-devel] Feature request: EASY-SSL-ACCEPTOR
by Daniel Brunner 30 Nov '11

30 Nov '11

Hi Hans, after reading the mailing list about the changes to the dispatch mechanism I learned that the *DISPATCH-TABLE* is only used with the EASY-ACCEPTOR class. Until now I was using the pre 1.2 SSL-ACCEPTOR with the *DISPATCH-TABLE*. A mentioned in your e-mail dated Oct 31 I now define a EASY-SSL-ACCEPTOR myself. But it would be nice to see that DEFCLASS in the official release. But maybe I am the only one using SSL with *DISPATCH-TABLE* then I can go with my own definition. Kind regards, Daniel

2 1

[hunchentoot-devel] default-handler
by Daniel Brunner 30 Nov '11

30 Nov '11

Hi, when I was upgrading to v.1.2.1 I learned that the default-handler functionality was gone. But the symbol *default-handler* is still in the export definition of packages.lisp. If that is not needed any more please find a patch attached with this line deleted. In the documentation there is still the description for DEFAULT-DISPATCHER and *DEFAULT-HANDLER*. But I was not sure how to fix that: Would it be sufficient to edit the index.xml? Kind regards, Daniel

2 1

[hunchentoot-devel] external-format and content-type question
by Vassilis Radis 10 Nov '11

10 Nov '11

I recently had this problem: I use sbcl + hunchentoot (current quicklisp supplied version) to serve cl-who generated content that contains non-ascii range utf-8 chars (greek letters). Initially i got the usual encoding error while processing a request. So I found the well known canonical solution: (setf *hunchentoot-default-external-format* (flex:make-external-format :utf8 :eol-style :lf)). The result is that the browser (chrome) displayed garbage where the greek letters should appear, although i set the default encoding of chrome to UTF-8 and i include the utf-8 meta tag in the content. I saw in the chrome tools that hunchentoot sent Latin-1 Http content-type header. This showed me that I needed to send the content-type-header manually and that Chrome (correctly IMO) ignores the user setting for the default encoding, if it receives a different HTTP content-type type header. So I set *default-content-type* and all is well now. But I came across the (reply-external-format*) function which confused me. Now, i am trying to clarify the functional co-relation or/and overlapping between those three: 1.setting *hunchentoot-default-external-format* 2.setting (reply-external-format*) --> is this just a per-request override of the *hunchentoot-default-external-format*? 3.sending the content-type header. --> Is there any legal scenario where we should report to the client something different than what is implied by (reply-external-format*)? What is the point of a default content-type header if there is a directly set default-external-format which also implicitly designates the header we should send? thanks in advance, Bill.

2 3

← Newer
1
...
5
6
7
8
9
10
11
...
87
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel