November 2011 - tbnl-devel@common-lisp.net

[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

[hunchentoot-devel] Hunchentoot v1.2.0 released
by Hans Hübner 05 Nov '11

05 Nov '11

After over a year of no releases, Hunchentoot v1.2.0 is out. It incorporates a large number of changes from various people and is the first release that I have made as the maintainer of Hunchentoot. There have been a fair number of changes, many of them contributed by Hunchentoot's users. Thank you all for that! The release tarball is available here: https://github.com/downloads/edicl/hunchentoot/hunchentoot-1.2.0.tar.gz This is my first release, and as such it is likely that I'm not yet up to the release standards that Edi has set forth. Please report any problems you may have with the new version to the Hunchentoot mailing list. I will try to resolve problems quickly and possible make a new minor release for each major problem found. The development repository for Hunchentoot is now hosted by github (https://github.com/edicl/hunchentoot) If you want to contribute, it would be appreciated if you could submit your patches through github, too. Here is a list of changes: Add www/ directory with default file tree that is being served Add error template mechanism and improve error reporting in general. Improve automatic testing, SBCL kludge to support asdf:test-op Allegro CL modern mode fixes Fix bugs in serving partial responses Limit maximum number of threads that Hunchentoot creates (Dan Weinreb, Scott McKay) Export fixes (Gordon Sims, Andrey Moskvitin) Factor out easy-handler logic into separate acceptor subclass Export two session functions (Nico de Jager) Allow no Content-Type header (Chaitanya Gupta) Patch for compilation with ECL (Sohail Somani) Fix DEFINE-EASY-HANDLER for multiple acceptors (Nicolas Neuss) Revived *SHOW-LISP-BACKTRACES-P* Made sure "100 Continue" is returned even if the client sends "Expect: 100-continue" twice (reported by Gordon Sims) Fixed typo in code which interprets transfer encodings Thank you for your patience! Hans

3 4

[hunchentoot-devel] Hunchentoot release 1.2.1
by Hans Hübner 04 Nov '11

04 Nov '11

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

1 0