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
Hans Hübner hans.huebner@gmail.com writes:
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.
Congratulations on the new release!
I've seen a number of projects affected by this release, but mostly for these reasons:
- no more HUNCHENTOOT:*APPROVED-RETURN-CODES* (affects cl-oauth, cl-twitter)
- no more HUNCHENTOOT:LOG-MESSAGE (affects hunchentoot-cgi)
- no more HUNCHENTOOT:ACCEPTOR-REQUEST-DISPATCHER (affects webfunk)
I didn't see these explicitly mentioned in your list of notable changes; is there any guidance for what should be used instead in each case?
Thanks, Zach
Hi Zach,
thank you for reporting the problems with quicklisp packages that depend on Hunchentoot. Unfortunately, due to the long time since the last release, there have been a number of small but incompatible changes that have accumulated and that would probably have received more prominent mention if they had been released timely. I will try to release quicker from now on.
Here are responses to your findings in quicklisp packages:
On Mon, Oct 31, 2011 at 2:08 AM, Zach Beane xach@xach.com wrote:
- no more HUNCHENTOOT:*APPROVED-RETURN-CODES* (affects cl-oauth, cl-twitter)
The whole concept of "approved" HTTP status codes is gone. Handlers are free to return whatever status code they require.
- no more HUNCHENTOOT:LOG-MESSAGE (affects hunchentoot-cgi)
ACCEPTOR-LOG-MESSAGE must be used instead. There is LOG-MESSAGE* which uses the current *ACCEPTOR*.
- no more HUNCHENTOOT:ACCEPTOR-REQUEST-DISPATCHER (affects webfunk)
Request dispatching is now done by the way of the generic ACCEPTOR-DISPATCH-REQUEST function. The *DISPATCH-TABLE* is only used with EASY-ACCEPTOR instances. For web frameworks that do their own request dispatching should implement a method for ACCEPTOR-DISPATCH-REQUEST, possibly with a CALL-NEXT-METHOD in the end if the request could not be dispatched.
Let me know if other issues come up or if I can provide more info.
-Hans
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
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 hans.huebner@gmail.com 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@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-
Bryan Emrys -
Hans Hübner -
Zach Beane