From hans.huebner at gmail.com Fri Nov 4 07:46:28 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 4 Nov 2011 08:46:28 +0100 Subject: [hunchentoot-devel] Hunchentoot release 1.2.1 Message-ID: Hi, I have made a new release of Hunchentoot, version 1.2.1. This release updates the documentation to describe the API changes since v1.1.1, in particular with respect to the easy handler framework. Also included are some bug fixes for SBCL/win32 by Anton Kovalenko and another fix from I. Perminov. Cheers, Hans From bryan.emrys at gmail.com Sat Nov 5 18:38:39 2011 From: bryan.emrys at gmail.com (Bryan Emrys) Date: Sat, 5 Nov 2011 11:38:39 -0700 Subject: [hunchentoot-devel] Hunchentoot v1.2.0 released In-Reply-To: References: <87aa8idl25.fsf@hangup.portland.xach.com> Message-ID: Just noting that I do use ssl and *dispatch-table*, so I would prefer having an easy-ssl-acceptor added to the next release. Thanks for all the hard work. Bryan On Mon, Oct 31, 2011 at 2:52 AM, Hans H?bner wrote: > I put some work into updating the documentation to reflect how request > processing is done. The documentation is now a bit more clear about > the base functionality and the functionality that is provided by > HUNCHENTOOT:EASY-ACCEPTOR. In a nutshell, if you have been using > DEFINE-EASY-HANDLER and/or *DISPATCH-TABLE* in the past, you'll want > to use EASY-ACCEPTOR instead of ACCEPTOR from now on. > > Currently, no EASY-SSL-ACCEPTOR class is defined. If you need it, you > can simply add it ( (defclass easy-ssl-acceptor (easy-acceptor > ssl-acceptor) ()) - If you do, please let me know so I'll add it to > the next release. > > I will wait a few more days to collect your input and make corrections > before I release v1.2.1 to include the documentation update and any > hot fixes that might be required. > > Thanks! > -Hans > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radisb at gmail.com Thu Nov 10 13:42:06 2011 From: radisb at gmail.com (Vassilis Radis) Date: Thu, 10 Nov 2011 15:42:06 +0200 Subject: [hunchentoot-devel] external-format and content-type question Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Thu Nov 10 14:12:19 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 10 Nov 2011 15:12:19 +0100 Subject: [hunchentoot-devel] external-format and content-type question In-Reply-To: References: Message-ID: Hi Bill, Let me try to answer your question with a description of how external formats in Hunchentoot are supposed to work. I am talking about Hunchentoot 1.2.0 specifically, as the behavior has changed since the 1.1 release family in the hope of making it easier to understand and use. External formats are meant to mostly work automatically. It should be enough to select a proper external format for the character set that you normally use and set *hunchentoot-default-external-format* to that. The new default character set since 1.2.0 is :utf-8, so most standard use cases should be covered. Also new with 1.2.0 is Hunchentoot's ability to automatically report the encoding used in replies sent. This is done by adding a charset= attribute to the reply content type, but only if the content type is a subtype of "text" (i.e. it does not affect, say, application/xml). This is independent of the *hunchentoot-default-external-format* setting, i.e. you can set (reply-external-format*) in your handler to something different from the default and still see the right charset be added to the content-type, if it is text. All this works for handlers that return strings, i.e. if you handler returns an octet vector or directly writes to the response stream, you are responsible for setting up the content-type in the reply properly yourself. If this does not work, please supply us with a specific case where and how it does not. Thanks! Hans On Thu, Nov 10, 2011 at 2:42 PM, Vassilis Radis wrote: > 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. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From radisb at gmail.com Thu Nov 10 15:37:01 2011 From: radisb at gmail.com (Vassilis Radis) Date: Thu, 10 Nov 2011 17:37:01 +0200 Subject: [hunchentoot-devel] external-format and content-type question In-Reply-To: References: Message-ID: Hans, Thank you for your quick answer. The only blur thing for me now is: How exactly hunchentoot understands what kind of content-type my handler's return string contains? Thanks, Bill On Thu, Nov 10, 2011 at 4:12 PM, Hans H?bner wrote: > Hi Bill, > > Let me try to answer your question with a description of how external > formats in Hunchentoot are supposed to work. I am talking about > Hunchentoot 1.2.0 specifically, as the behavior has changed since the > 1.1 release family in the hope of making it easier to understand and > use. > > External formats are meant to mostly work automatically. It should be > enough to select a proper external format for the character set that > you normally use and set *hunchentoot-default-external-format* to > that. The new default character set since 1.2.0 is :utf-8, so most > standard use cases should be covered. > > Also new with 1.2.0 is Hunchentoot's ability to automatically report > the encoding used in replies sent. This is done by adding a charset= > attribute to the reply content type, but only if the content type is a > subtype of "text" (i.e. it does not affect, say, application/xml). > This is independent of the *hunchentoot-default-external-format* > setting, i.e. you can set (reply-external-format*) in your handler to > something different from the default and still see the right charset > be added to the content-type, if it is text. > > All this works for handlers that return strings, i.e. if you handler > returns an octet vector or directly writes to the response stream, you > are responsible for setting up the content-type in the reply properly > yourself. > > If this does not work, please supply us with a specific case where and > how it does not. > > Thanks! > Hans > > On Thu, Nov 10, 2011 at 2:42 PM, Vassilis Radis wrote: > > 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. > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Thu Nov 10 15:44:15 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 10 Nov 2011 16:44:15 +0100 Subject: [hunchentoot-devel] external-format and content-type question In-Reply-To: References: Message-ID: On Thu, Nov 10, 2011 at 4:37 PM, Vassilis Radis wrote: > How exactly hunchentoot understands what kind of content-type my handler's > return string contains? It understands nothing about the content type. All it does is add a "charset" attribute to the content-type header if the returned content is a string and the content type begins with "text/". Your handlers still have to set the content type to the appropriate base type, but they don't need (and should not) set a charset attribute because that is automatically determined by Hunchentoot (through the external format). Let us know if you have further questions. -Hans From daniel at dbrunner.de Tue Nov 29 09:31:05 2011 From: daniel at dbrunner.de (Daniel Brunner) Date: Tue, 29 Nov 2011 10:31:05 +0100 Subject: [hunchentoot-devel] default-handler Message-ID: <4ED4A659.2070709@dbrunner.de> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixed-exported-symbols.patch Type: text/x-patch Size: 676 bytes Desc: not available URL: From daniel at dbrunner.de Tue Nov 29 11:16:35 2011 From: daniel at dbrunner.de (Daniel Brunner) Date: Tue, 29 Nov 2011 12:16:35 +0100 Subject: [hunchentoot-devel] Feature request: EASY-SSL-ACCEPTOR Message-ID: <4ED4BF13.6010507@dbrunner.de> 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 From hans.huebner at gmail.com Wed Nov 30 18:38:02 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 30 Nov 2011 19:38:02 +0100 Subject: [hunchentoot-devel] default-handler In-Reply-To: <4ED4A659.2070709@dbrunner.de> References: <4ED4A659.2070709@dbrunner.de> Message-ID: Hi Daniel, thanks for the patch. I have applied it and also fixed the documentation. Changing index.xml is sufficient, for the next time. Thanks again, Hans On Tue, Nov 29, 2011 at 10:31 AM, Daniel Brunner wrote: > 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 > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From hans.huebner at gmail.com Wed Nov 30 20:27:26 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 30 Nov 2011 21:27:26 +0100 Subject: [hunchentoot-devel] Feature request: EASY-SSL-ACCEPTOR In-Reply-To: <4ED4BF13.6010507@dbrunner.de> References: <4ED4BF13.6010507@dbrunner.de> Message-ID: Hi Daniel, On Tue, Nov 29, 2011 at 12:16 PM, Daniel Brunner wrote: > 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. This suggestion has been on the github issues list for a while and is no implemented. The issues list is a good place to post suggestions and bug reports to: https://github.com/edicl/hunchentoot/issues?sort=created&direction=desc&state=open Thanks! Hans From hans.huebner at gmail.com Wed Nov 30 20:29:49 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 30 Nov 2011 21:29:49 +0100 Subject: [hunchentoot-devel] Hunchentoot release 1.2.2 Message-ID: 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