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

[hunchentoot-devel] Charset assumptions, in particular in POST bodies
by Red Daly 05 Jun '10

05 Jun '10

About 6 months ago I got some strange encoding errors with a Hunchentoot web server. There are a few of places in Hunchentoot where the +latin-1+ character encoding is used as the external format regardless of headers received from the client: - GET-POST-DATA returns a +latin-1+ externally encoded stream no matter what when the WANT-STREAM parameter is true. - PARSE-MULTIPART-FORM-DATA creates a +latin-1+ stream from the CONTENT-STREAM of the request. (relevant RFC: 2388) - MAYBE-READ-POST-PARAMETERS uses +latin-1+ to process "application/x-www-form-urlencoded" content-type POST bodies In addition, RECOMPUTE-REQUEST-PARAMETERS seems to interpret both the message body and the query string according to a charset in the request header. I thought that Content-Type was only supposed to affect the message body, not the headers (which are assumed to be in ASCII). Then shouldn't the URL and query string always be read as ASCII? RFC2047 discusses non-ascii headers for MIME, but I don't know if that is relevant except for parsing multipart forms. I'm not thoroughly versed in the HTTP protocol, but it seems that these are bugs in Hunchentoot. I have a half-completed patch but I want to get some more opinions before I go any further. There may also be other lurking encoding issues in Hunchentoot, or I may be entirely mistaken. Proposed solution: - GET-POST-DATA, PARSE-MULTIPART-FORM-DATA, and MAYBE-READ-POST-PARAMETERS should respect the Content-Type header in the request and use that to define the external-format of the stream used to parse - RECOMPUTE-REQUEST-PARAMETERS should only use the Content-Type external format to parse the post parameters - PARSE-MULTIPART-FORM-DATA may need additional review to be in accordance with RFC2047 and RFC2388 Feedback, please. Thanks, Red

2 1

[hunchentoot-devel] caching and create-folder-dispatcher-and-handler
by Patrick May 04 Jun '10

04 Jun '10

Is it possible to set max-age or no-cache with create-folder-dispatcher-and-handler? I have some audio files that change infrequently and one of my clients is caching them and not catching the changes. Thanks, Patrick

1 0

[hunchentoot-devel] Session Time Out - HELP!
by Phil Marneweck 21 May '10

21 May '10

Hi Is there any thing more than *session-gc-frequency* and *session-max-time* that influences session time outs? Because it does not matter how high I set these values the session keeps on timing out with in a couple of minutes! Can those values be set at any time or do they have to be set before any acceptors are created? Any help would be much appreciated this is causing me major pain on a live site.

3 17

[hunchentoot-devel] Oh! Let me float in your pool!
by Gordon Sims 15 May '10

15 May '10

DRAKMA: [singing] ...Yes, YOU'RE ALL REAL COOL, with those little WEBS you SPOOL and all your 'SPIDER DROOL'... Oh! Let me float in your pool! HUNCHENTOOT: [disgruntled] "What you want NOW, bitch?" -- GORDON: [ambitiously hacking] I'd like to have two settings in Hunchentoot to control the maximum number of worker threads, and how many connections are accepted (and queued) for processing when the maximum is exceeded. If the maximum is exceeded, new connection attempts should be refused. This is analogous to Tomcat's maxThreads and acceptCount settings. It could be implemented by a pool of worker threads. Is this a concept that anybody has experimented yet with current version of Hunchentoot? Are there any thoughts about how a thread pool should work, especially the coordination (or division of responsibility) between ACCEPTOR and TASKMASTER objects? Any portability concerns? thanks, -Gordon

2 1

[hunchentoot-devel] static-file-dispatcher-and-handler for specific acceptor
by Phil Marneweck 15 May '10

15 May '10

Hi How do I make create-static-file-dispatcher-and-handler to be relevant for a specific acceptor only? Usually I would just push it onto the *dispatch-table*, but that is global. Or am I missing something obvious again? Thanx

2 1

[hunchentoot-devel] authorization fail to redirect?
by J. K. Cunningham 11 May '10

11 May '10

Hi, Is there a relatively simple way to make REQUIRE-AUTHORIZATION fail to the REDIRECT function so the user doesn't see the error return response? I've tried a number of things without success so far. I would like to have it work so that the user can back out gracefully if he hits "Cancel" rather than attempt a username-password. Redirecting to the page of origin would be perfect. Thanks. Jeff Cunningham

1 0

[hunchentoot-devel] hunchentoot page not rendering correctly in two recent browsers
by Cunningham, Jeffrey K. 10 May '10

10 May '10

Here at work I have available Epiphany 2.28.0 and Firefox 3.5.7 (both Linux). The latter renders the http://weitz.de/hunchentoot <http://weitz.de/hunchentoot> page with errors (looks like some of the head section is coming out as HTML before the first h1 tag), and the former refuses to render it at all - producing "This page contains the following errors:..." message. I have attached pngs of each for troubleshooting, though I don't know if they will go through the list server. If not I will post them on another server tonight and post a link. Both browsers are set up with defaults as installed in US. Jeffrey Cunningham Space Systems Development Division Space & Geospatial Intelligence Business Unit Science Applications International Corporation ph: 253.867.3792 fx: 253.867.1504 jeffrey.k.cunningham(a)saic.com <mailto:jeffrey.k.cunningham@saic.com>

2 1

Re: [hunchentoot-devel] hunchentoot page not rendering correctly in two recent browsers
by Cunningham, Jeffrey K. 10 May '10

10 May '10

Forgot the attachments JKC ________________________________ From: Cunningham, Jeffrey K. Sent: Monday, May 10, 2010 2:42 PM To: 'tbnl-devel(a)common-lisp.net' Subject: hunchentoot page not rendering correctly in two recent browsers Here at work I have available Epiphany 2.28.0 and Firefox 3.5.7 (both Linux). The latter renders the http://weitz.de/hunchentoot <http://weitz.de/hunchentoot> page with errors (looks like some of the head section is coming out as HTML before the first h1 tag), and the former refuses to render it at all - producing "This page contains the following errors:..." message. I have attached pngs of each for troubleshooting, though I don't know if they will go through the list server. If not I will post them on another server tonight and post a link. Both browsers are set up with defaults as installed in US. Jeffrey Cunningham Space Systems Development Division Space & Geospatial Intelligence Business Unit Science Applications International Corporation ph: 253.867.3792 fx: 253.867.1504 jeffrey.k.cunningham(a)saic.com <mailto:jeffrey.k.cunningham@saic.com>

1 0

[hunchentoot-devel] Patches for ABCL to hunchentoot, trivial-gray-streams, flexi-streams, and chunga
by Mark Evenson 08 May '10

08 May '10

I've [assembled instructions for running Hunchentoot on ABCL][1], which includes minor patches to hunchentoot, trivial-gray-streams, flexi-streams, and chunga. The patches seem to be tested well enough now that I ask that the respective package maintainers consider applying the patches to their distribution. Hopefully, all the package maintainers will see this message, although I'm not quite sure about the status of trivial-gray-streams, so corrections and/or forwarding to the proper maintainers are solicited. If package maintainers have further work or critiques to the proposed patches that I should do, please don't hesitate to ask. [1]: http://slack.net/~evenson/abcl/hunchentoot/ -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

[hunchentoot-devel] parameter-type hash-table encoded with [] or {}
by Knut Olav Bøhmer 23 Apr '10

23 Apr '10

Hi, When I post json objects from jquery $.ajax({ type: 'POST', url: '/url', dataType: 'json', data: {"key":"val","hash",{"foo":"bar"}} then the "hash" parameter is posted like this: "hash[foo]=bar" If I then in hunchentoot have (define-easy-handler (fn :uri "/url") ((hash :parameter-type 'hash-table)) ..... The hash is expected to be posted like this: "hash{foo}=bar"? So I wonder if it would be correct to enable the "hash[foo]=bar" syntax for hash tables. Maybe it should be an argument that specifies if compute-hash-table-parameter should use [] or {}. This little experiment worked for me, here I just added \\[ and \\] to the regexp. Should I bother to make a patch? (defun compute-hash-table-parameter (parameter-name type parameters key-type test-function) "Retrieves all parameters from PARAMETERS which are named like \"PARAMETER-NAME{FOO}\" or \"PARAMETER-NAME[FOO]\" \(where FOO is any sequence of characters not containing curly brackets), converts them to TYPE, and returns a hash table with test function TEST-FUNCTION where the corresponding value is associated with the key FOO \(converted to KEY-TYPE)." (let ((hash-table (make-hash-table :test test-function))) (loop for (full-name . value) in parameters for key = (register-groups-bind (name key-string) ("^(.*)[{\\[]([^\\[\\]{}]+)[}\\]]$" full-name) (when (string= name parameter-name) (convert-parameter key-string key-type))) when key do (setf (gethash key hash-table) (convert-parameter value type))) hash-table)) -- Knut Olav Bøhmer

3 4