March 2010 - tbnl-devel@common-lisp.net - mailman3.common-lisp.net

[hunchentoot-devel] maybe bug + patch
by Richard KLINDA 06 Jun '10

06 Jun '10

Hello, I may have found a bug. After stopping an acceptor with STOP, one can't start it again with START, because the START method doesn't reset the value of acceptor-shutdown-p to NIL, so the listener returns/quits instantly. See the attached trivial patch, that fixes the issue for me, but maybe I'm just missing something here. -- Richard

3 2

[hunchentoot-devel] PATCH: simplify debugging of remote servers
by Andrey Moskvitin 07 Apr '10

07 Apr '10

I know that for production installations, it is not advisable to have *CATCH-ERRORS-P* to be set to NIL. But it is often necessary to debug of remote server. Attached is my patch that simplifies this process. It limits the number of active calls invoke-debugger and destroys debugging threads after closing the connection with a swank-server. Andrey

3 11

[hunchentoot-devel] How to properly write directly to output stream?
by Vsevolod Dyomkin 30 Mar '10

30 Mar '10

Hi, I'm developing a new web-application, based on Hunchentoot 1.1, my previous ones were based on pre-1.0 version. Since there was a switch to binary-streams, the following approach to HTML generation directly to the input stream from CL-WHO, which I'd used previously had to be modified from (let ((out (send-headers))) (with-html-output (*who-stream* out) ;; ... to (let ((out (flex:make-flexi-stream (send-headers) :external-format *hunchentoot-default-external-format* :element-type 'character))) (with-html-output (*who-stream* out) ;; ... Still it doesn't perform the same as before, because, as far as I understand, of the new handling of chunking. It seems to me, that the chunk size is set to 8K in Chunga and in my case that's very inconvenient: I'd like to serve the page in many small portions, as the time of their "arrival" is quite unpredictable. That is why I've tried to turn off chunking or set lower chunk sizes (1K, for example) via both the public API (acceptor-output-chunking-p) and by manipulating the Hunchentoot internals, but failed to achieve anything. Either only the headers are sent and the connection is closed, or I need to wait until the handler returns. I would be grateful, if someone, who better understands the internal mechanisms of that, gave me an explanation and some advice. Thanks in advance, Vsevolod Dyomkin

3 2

[hunchentoot-devel] Trivial patch for potential XSS bugs
by J.P. Larocque 30 Mar '10

30 Mar '10

Hi, There are a few places where Hunchentoot generates HTML which directly include some strings, but the strings are plain-text and not HTML. In some cases you can see that the string can never coincidentally contain HTML or user-supplied input, so that's fine--I haven't touched these. In other cases, the string is determined from user input (at the HTTP level), so there's a danger of XSS attacks at these points. The chance of a successful attack which exploits these flaws is probably low. In any case, I think Hunchentoot should always correctly encode these user-supplied strings as HTML, since the strings are treated as plain-text and are not already formatted as HTML. A patch is attached. The changes are minimal and should speak for themselves. Thanks, -- J.P. Larocque <jpl(a)thoughtcrime.us>

2 1

[hunchentoot-devel] *approved-return-codes*
by helmut＠cybernetic-systems.de 30 Mar '10

30 Mar '10

Is ist possible to add +http-created+ to the *approved-return-codes* list? Dojo jsonRestStore's post method requires a +http-created+, a +http-ok+ ist not enough. By default a +http-create+ returns a '<html> ...Created ...</html>' string and not my json text. But I can not appaise the effects. Helmut

2 1

[hunchentoot-devel] suggested imporvement: setting content-type with keywords
by Ala'a (cmo-0) 23 Mar '10

23 Mar '10

Hi, Here is a patch against the stable release of hunchentoot 1.1.0. This patch will allow the API users to set the content type via keywords, for example: (setf (content-type*) :pdf) or :jpeg, :svg, :css plus the normal usage (setf (content-type*) "application/pdf") regards, Ala'a (cmo-0)

2 3

[hunchentoot-devel] Probably a bug in url-encode/url-decode
by Andrey Moskvitin 19 Mar '10

19 Mar '10

Hi, I encountered the following problem: CL-USER> (hunchentoot:url-decode "+") " " CL-USER> (hunchentoot:url-encode "+") "%2B" But in JavaScript: >>> encodeURI("+") "+" >>> decodeURI("+") "+" This is a bug? Andrey

4 7

[hunchentoot-devel] ht-wfx (widget framework)
by Phil Marneweck 18 Mar '10

18 Mar '10

Some time ago I suggested a simlple widget framework for hunchentoot and got a mixed bag of reaction. I have finally gotten round to creating something in that line. It is a thin layer over hunchentoot, but hopefully has enough functionality to help web development some what. Any feedback will be welcomed. http://bitbucket.org/harag/ht-wfx/wiki/Home

1 0

[hunchentoot-devel] Hunchentoot treatment of unhandled conditions
by Daniel Weinreb 02 Mar '10

02 Mar '10

We just ran into a problem regarding Hunchntoot's handling of unexpected conditions. Hunchentoot's accept-connections called usocket:socket-accept, which signaled a usocket:unknown-error. Nothing handled this condition. This happened in a server, which crashes (rather than going into the interactive debugger) when there is an unhandled condition. I'd like to have a way to do something like this in Hunchentoot. I see that the latest version goes further in this direction by having a handler-bind for "error" in the handle-request method. Unfortunately, in our case, the problem occurs before that is in effect. Are there any plans regarding this, or advice about it? Thanks. -- Dan

2 3