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

[hunchentoot-devel] Hunchentoot effective DOS-attack
by Semion Prikhodko 21 Apr '10

21 Apr '10

Hi, guys. I have exactly the problem described in http://common-lisp.net/pipermail/tbnl-devel/2009-July/004757.html I have found there a patch: http://bknr.net/trac/changeset/4435?format=diff&new=4435 but seems it cannot be applied on my vesion of Hunchentoot (mine is 1.0.0, it slightly different). Is this issue fixed in Hunchentoot 1.1? Thanks in advance.

2 1

[hunchentoot-devel] Hunchentoot effective DOS-attack
by Semion Prikhodko 21 Apr '10

21 Apr '10

Hi, guys. I have exactly the problem described in http://common-lisp.net/pipermail/tbnl-devel/2009-July/004757.html I have found there a patch: http://bknr.net/trac/changeset/4435?format=diff&new=4435 but seems it cannot be applied on my vesion of Hunchentoot (mine is 1.0.0, it slightly different). Is this issue fixed in Hunchentoot 1.1? Thanks in advance.

1 0

[hunchentoot-devel] Status of Kevin Rosenberg and b9.com?
by Jeremy Reimer 16 Apr '10

16 Apr '10

Hello, I am getting into LISP and I have found the wonderful Hunchentoot web server project. I am in the process of installing it but I have run into a strange roadblock. I have installed SBCL and Slime, and I am at this point: $ sudo sbcl * (require 'asdf-install) * (asdf-install:install :hunchentoot) The asdf installer scripts reference some dependencies such as MD5 and CL-BASE64, which attempt to download packages at files.b9.com, run by Kevin Rosenberg, but *.b9.com is currently not responding at all (and hasn’t for several days) and there seems to be no way to contact Kevin to inquire about the status of his web sites. Do you know what has happened to Kevin? And if not, how can I install Hutchentoot? Thank you for any help you can give me! Jeremy

2 3

[hunchentoot-devel] UTF-8 encoding problems
by Sebastian Tennant 14 Apr '10

14 Apr '10

Hi all, CL-USER> (hunchentoot-asd:*hunchentoot-version*) "1.1.0" With: (setq tbnl:*default-content-type* "text/html; charset=utf-8") called once when TBNL is initialised, Turkish characters provided in Lisp source files are sent to the client without a problem, but Turkish characters that come from a UTF-8 database via Postmodern cause the following error: Error while processing connection: #\LATIN_SMALL_LETTER_DOTLESS_I (code 305) is not a LATIN-1 character. before they can be sent to the client. Why does TBNL expect LATIN-1 characters in one context but not in another? Incidentally, I experience the same 'not a LATIN-1 character' error when I evaluate Lisp files via SLIME, but not when the files are load'ed. Putting: (setf (content-type*) "text/html; charset=utf-8") in the handler makes no difference. What else can I try? Seb P.S. Turkish characters in the results of Postmodern queries performed directly in the REPL are displayed (in SLIME) correctly. -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap

2 2

Re: [hunchentoot-devel] suggested imporvement: setting content-type with keywords
by Edi Weitz 07 Apr '10

07 Apr '10

I'm taking this back to the mailing list. I think there's no need to discuss this in private. FWIW, I agree with Hans and don't think this is a very useful patch. You argue that with the patch you won't have to memorize mime types, but then you'll have to memorize file suffixes instead. And even if you don't need to learn them (as many of those suffixes have become second nature to us), they are a pretty arbitrary classification from the olden days of operating systems. Finally, how many different mime types will you use in a typical web application? Is it such a big deal? Thanks, Edi. On Wed, Apr 7, 2010 at 12:05 AM, Hans Hübner <hans.huebner(a)gmail.com> wrote: > Ala'a, > > hereby I forward your reply to Edi. I think the basic concern is that > MIME types are standardized, whereas keywords are not, and that it is > not clear what keywords are supported and how keywords would be added. > I agree with you that abstraction is good, but it is good only if it > does not break easily, because, say, no new MIME types can be added, > or there is ambiguity between MIME types and keywords as in the case > of XML. Sometimes, something that first seemed simple and > straightforward becomes cumbersome and ugly. This is not to say that > your patch is in that class, I'm just saying that there may be valid > counterarguments against including such a simple thing in the base > HTTP surrogate because it does not scale beyond the simple use cases > provoided as example. > > That said, let's see if Edi has an opinion. > > -Hans > > > ---------- Forwarded message ---------- > From: Ala'a (cmo-0) <amalawi(a)gmail.com> > Date: Tue, Apr 6, 2010 at 19:16 > Subject: Re: [hunchentoot-devel] suggested imporvement: setting > content-type with keywords > To: Hans Hübner <hans.huebner(a)gmail.com> > > > Hi Hans, > > I understand, thus the followings are the motives/notes/thoughts > regarding the patch: > > - As a developer I do not want to be concerned/or memorize that > sending pdf should be > using "application/pdf". The details of mime types should be hidden > (a kind of abstraction) > in other words, moving from constructing the details of the response > (as much as possible), > and concentrating on the task at hand which is developing the web > content (js, ajax, html > and other content dynamic and/or static). In general there is no > productivity boost, except > to avoid looking for the right mime type, Is it > application/something? or text/something? > Maybe its time for googling mime types again ;) > > - There are some uses of keyword designators in the API (like in > *lisp-errors-log-level* and > the use of :post :get and :both in define-esay-handler) which could > be strings, so I > thought/assumed that my patch will not be a stranger within the current API. > > - Still the API is backward compatible, there is no need to force the > users to use the new > designator. And the code uses the already built in database for mime types. > > - This patch can propagate the API abstraction upward and be used by > other extension (maybe another patch) like: > (defun set-content-spec (mime-type-designator &optional > disposition-type filename) ...) > where > mime-type-designator: the same value as taken by (setf content-type*). > filename: the name of sent content. > disposition-type: is either :inline (open within the browser) or > :attachment (open a save-as dialog). > so I can say something like: > (defun lpo-pdf () > (let ((lpo (query-for-lpo ...))) ;lpo is short for: local purchase order > (set-content-spec :pdf :attachment (format nil "~A.pdf" (serial lpo))) > (generate-pdf-content))) > > sheesh, this is almost triple the size of the patch ;) > > Regards, > > Ala'a (cmo-0) > >

2 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