From hans at huebner.org Mon Sep 1 07:38:31 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 1 Sep 2008 09:38:31 +0200 Subject: [hunchentoot-devel] Request methods suffixed with * -- not backwards compatible? In-Reply-To: <48BA27A9.6020508@chaitanyagupta.com> References: <48BA27A9.6020508@chaitanyagupta.com> Message-ID: On Sun, Aug 31, 2008 at 07:10, Chaitanya Gupta wrote: > Hi, > > I was trying to use the svn branch of Hunchentoot, and found, to my > surprise, that most of my old code didn't work anymore. The culprit mainly > seems to be request.lisp, where a lot of old functions/methods have been > renamed with a * suffixed to their name. > > Are these changes permanent? Will these make it into the release version? > Also, what is the reason behind this? I tried searching the mailing list for > any discussion on this, but couldn't find anything. We found that it was very inconvenient that there are no accessor functions for the slots in the request object, and that the accessors should be conventionally named. I think we are not completely done with the API cleanup, though, and it may well be that there will be further changes before the next real release (i.e. the reply class may be changed, too). It is propably safe to assume that the *-versions of the accessors will stay forever. -Hans From mail at chaitanyagupta.com Mon Sep 1 13:08:44 2008 From: mail at chaitanyagupta.com (Chaitanya Gupta) Date: Mon, 01 Sep 2008 18:38:44 +0530 Subject: [hunchentoot-devel] Request methods suffixed with * -- not backwards compatible? In-Reply-To: References: <48BA27A9.6020508@chaitanyagupta.com> Message-ID: <48BBE95C.90001@chaitanyagupta.com> Hans H?bner wrote: > We found that it was very inconvenient that there are no accessor > functions for the slots in the request object, and that the accessors > should be conventionally named. I think we are not completely done > with the API cleanup, though, and it may well be that there will be > further changes before the next real release (i.e. the reply class may > be changed, too). It is propably safe to assume that the *-versions > of the accessors will stay forever. > > Ok. But does it mean that code written for the current release version of hunchentoot will break? As of now, I can't really use our existing code with the dev version, which is quite a dampener.. Chaitanya From hans at huebner.org Mon Sep 1 13:27:44 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 1 Sep 2008 15:27:44 +0200 Subject: [hunchentoot-devel] Request methods suffixed with * -- not backwards compatible? In-Reply-To: <48BBE95C.90001@chaitanyagupta.com> References: <48BA27A9.6020508@chaitanyagupta.com> <48BBE95C.90001@chaitanyagupta.com> Message-ID: On Mon, Sep 1, 2008 at 15:08, Chaitanya Gupta wrote: > Hans H?bner wrote: >> >> We found that it was very inconvenient that there are no accessor >> functions for the slots in the request object, and that the accessors >> should be conventionally named. I think we are not completely done >> with the API cleanup, though, and it may well be that there will be >> further changes before the next real release (i.e. the reply class may >> be changed, too). It is propably safe to assume that the *-versions >> of the accessors will stay forever. >> >> > > Ok. But does it mean that code written for the current release version of > hunchentoot will break? As of now, I can't really use our existing code with > the dev version, which is quite a dampener.. Yes. Code for the current release version of Hunchentoot will not be compatible to code for the next release version. You need to either stay with the old release, code for the new release and use the dev version or port forward once the new release is out. The new release is will take several weeks to show up. -Hans From mail at chaitanyagupta.com Mon Sep 1 16:21:20 2008 From: mail at chaitanyagupta.com (Chaitanya Gupta) Date: Mon, 1 Sep 2008 21:51:20 +0530 Subject: [hunchentoot-devel] Request methods suffixed with * -- not backwards compatible? In-Reply-To: References: <48BA27A9.6020508@chaitanyagupta.com> <48BBE95C.90001@chaitanyagupta.com> Message-ID: <2079faf0809010921kbba2024w2570f1fe4d2407f6@mail.gmail.com> On Mon, Sep 1, 2008 at 6:57 PM, Hans H?bner wrote: > > Yes. Code for the current release version of Hunchentoot will not be > compatible to code for the next release version. You need to either > stay with the old release, code for the new release and use the dev > version or port forward once the new release is out. The new release > is will take several weeks to show up. :( Does it have to break so badly? I don't see the *-suffixed versions giving any real advantage, and the slot accessors can just be renamed to something else -- e.g. request-get-parameters, etc. -- instead of currently exported symbols. Chaitanya From edi at agharta.de Mon Sep 1 17:59:50 2008 From: edi at agharta.de (Edi Weitz) Date: Mon, 01 Sep 2008 19:59:50 +0200 Subject: [hunchentoot-devel] Request methods suffixed with * -- not backwards compatible? In-Reply-To: <2079faf0809010921kbba2024w2570f1fe4d2407f6@mail.gmail.com> (Chaitanya Gupta's message of "Mon, 1 Sep 2008 21:51:20 +0530") References: <48BA27A9.6020508@chaitanyagupta.com> <48BBE95C.90001@chaitanyagupta.com> <2079faf0809010921kbba2024w2570f1fe4d2407f6@mail.gmail.com> Message-ID: On Mon, 1 Sep 2008 21:51:20 +0530, "Chaitanya Gupta" wrote: > Does it have to break so badly? Yes. Except that I wouldn't call it "break". Generally, I think it is better to introduce several incompatible changes at once than to do it piecemeal with every release. > I don't see the *-suffixed versions giving any real advantage, and > the slot accessors can just be renamed to something else -- > e.g. request-get-parameters, etc. -- instead of currently exported > symbols. We thought about this as well and eventually decided to go this way. One of the goals of the new release is a clearer CLOS-based model of the request/response phase and we think that the names should reflect this. I'm usually trying to be as backwards-compatible as possible (mind you, I have to update my web apps as well!), but sometimes it simply isn't possible. As Hans said, if you think the new release doesn't buy you anything, you are free to stick with the previous one. You can even have both for the price of one. (Special offer, will only last until Halloween!) Cheers, Edi. From ch-tbnl at bobobeach.com Mon Sep 1 22:58:05 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Mon, 1 Sep 2008 15:58:05 -0700 Subject: [hunchentoot-devel] Request methods suffixed with * -- not backwards compatible? In-Reply-To: References: <48BA27A9.6020508@chaitanyagupta.com> <48BBE95C.90001@chaitanyagupta.com> <2079faf0809010921kbba2024w2570f1fe4d2407f6@mail.gmail.com> Message-ID: On thing that could be done would be to introduce the *'ed symbols into a maintenance release of the old hunchentoot such that calls to say (script-name) in the current codebase can then be (script-name*) which should work with the new regime. that might help ease the transition. just a thought... cyrus On Sep 1, 2008, at 10:59 AM, Edi Weitz wrote: > On Mon, 1 Sep 2008 21:51:20 +0530, "Chaitanya Gupta" > wrote: > >> Does it have to break so badly? > > Yes. Except that I wouldn't call it "break". Generally, I think it > is better to introduce several incompatible changes at once than to do > it piecemeal with every release. > >> I don't see the *-suffixed versions giving any real advantage, and >> the slot accessors can just be renamed to something else -- >> e.g. request-get-parameters, etc. -- instead of currently exported >> symbols. > > We thought about this as well and eventually decided to go this way. > One of the goals of the new release is a clearer CLOS-based model of > the request/response phase and we think that the names should reflect > this. I'm usually trying to be as backwards-compatible as possible > (mind you, I have to update my web apps as well!), but sometimes it > simply isn't possible. > > As Hans said, if you think the new release doesn't buy you anything, > you are free to stick with the previous one. You can even have both > for the price of one. (Special offer, will only last until > Halloween!) > > Cheers, > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From lispercat at gmail.com Tue Sep 2 18:03:57 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Tue, 2 Sep 2008 14:03:57 -0400 Subject: [hunchentoot-devel] utf-8 encoding problems Message-ID: I have problems with some of the utf-8 characters in sbcl 1.0.18 and hunchentoot-0.15.7 (Ubuntu) When I create a handler like this: (defun test-handler () (no-cache) (recompute-request-parameters :external-format (flex:make-external-format :utf-8 :eol-style :lf)) (setf (hunchentoot:content-type) "text/html; charset=utf-8") (with-html-output-to-string (*standard-output* nil :prologue nil :indent nil) (:html (:head (:title "Test page")) (:body (:p ""quotation""))))) Where I have those "right and left quotation marks" I get an error: #\LEFT_DOUBLE_QUOTATION_MARK (code 8220) is not a LATIN-1 character. [Condition of type FLEXI-STREAMS:EXTERNAL-FORMAT-ENCODING-ERROR] If, on the other hand, I set global variable *hunchentoot-default-external-format* to utf-8 (setf *hunchentoot-default-external-format* (flex:make-external-format :utf-8 :eol-style :lf)) then everything works. I just want one handler to handle the uft-8 encoding, how can I fix it? Thank you, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From lispercat at gmail.com Tue Sep 2 19:41:44 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Tue, 2 Sep 2008 15:41:44 -0400 Subject: [hunchentoot-devel] Re: utf-8 encoding problems In-Reply-To: References: Message-ID: The email system replaced the quotation marks to the regular ones. What I meant was the quotation marks described here . On Tue, Sep 2, 2008 at 2:03 PM, Andrei Stebakov wrote: > I have problems with some of the utf-8 characters in sbcl 1.0.18 and > hunchentoot-0.15.7 (Ubuntu) > When I create a handler like this: > > (defun test-handler () > (no-cache) > (recompute-request-parameters :external-format (flex:make-external-format > :utf-8 :eol-style :lf)) > (setf (hunchentoot:content-type) "text/html; charset=utf-8") > (with-html-output-to-string (*standard-output* nil :prologue nil :indent > nil) > (:html > (:head > (:title "Test page")) > (:body > (:p > > ""quotation""))))) > > > Where I have those "right and left quotation marks" I get an error: > #\LEFT_DOUBLE_QUOTATION_MARK (code 8220) is not a LATIN-1 character. > [Condition of type FLEXI-STREAMS:EXTERNAL-FORMAT-ENCODING-ERROR] > > If, on the other hand, I set global variable > *hunchentoot-default-external-format* to utf-8 > (setf *hunchentoot-default-external-format* (flex:make-external-format > :utf-8 :eol-style :lf)) > then everything works. > I just want one handler to handle the uft-8 encoding, how can I fix it? > > Thank you, > Andrew > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lispercat at gmail.com Tue Sep 2 20:32:09 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Tue, 2 Sep 2008 16:32:09 -0400 Subject: [hunchentoot-devel] Re: utf-8 encoding problems In-Reply-To: References: Message-ID: No luck emailing the quotation marks. Let's try a German character '?' (defun test-handler () (no-cache) (recompute-request-parameters :external-format (flex:make-external-format :utf-8 :eol-style :lf)) (setf (hunchentoot:content-type) "text/html; charset=utf-8") (with-html-output-to-string (*standard-output* nil :prologue nil :indent nil) (:html (:head (:title "Test page")) (:body (:p "wei?"))))) Will produce text like "wei?" If I set the global variable: (setf *hunchentoot-default-external-format* (flex:make-external-format :utf-8 :eol-style :lf)) the problem gets fixed. Andrew On Tue, Sep 2, 2008 at 2:03 PM, Andrei Stebakov wrote: > I have problems with some of the utf-8 characters in sbcl 1.0.18 and > hunchentoot-0.15.7 (Ubuntu) > When I create a handler like this: > > (defun test-handler () > (no-cache) > (recompute-request-parameters :external-format (flex:make-external-format > :utf-8 :eol-style :lf)) > (setf (hunchentoot:content-type) "text/html; charset=utf-8") > (with-html-output-to-string (*standard-output* nil :prologue nil :indent > nil) > (:html > (:head > (:title "Test page")) > (:body > (:p > > ""quotation""))))) > > > Where I have those "right and left quotation marks" I get an error: > #\LEFT_DOUBLE_QUOTATION_MARK (code 8220) is not a LATIN-1 character. > [Condition of type FLEXI-STREAMS:EXTERNAL-FORMAT-ENCODING-ERROR] > > If, on the other hand, I set global variable > *hunchentoot-default-external-format* to utf-8 > (setf *hunchentoot-default-external-format* (flex:make-external-format > :utf-8 :eol-style :lf)) > then everything works. > I just want one handler to handle the uft-8 encoding, how can I fix it? > > Thank you, > Andrew > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsynnott at gmail.com Tue Sep 2 20:38:16 2008 From: rsynnott at gmail.com (Robert Synnott) Date: Tue, 2 Sep 2008 21:38:16 +0100 Subject: [hunchentoot-devel] Re: utf-8 encoding problems In-Reply-To: References: Message-ID: <24f203480809021338o761c3ee2r1588eed12fda8db9@mail.gmail.com> 2008/9/2 Andrei Stebakov : > No luck emailing the quotation marks. Let's try a German character '?' > > (defun test-handler () > (no-cache) > (recompute-request-parameters :external-format (flex:make-external-format > :utf-8 :eol-style :lf)) > (setf (hunchentoot:content-type) "text/html; charset=utf-8") > (with-html-output-to-string (*standard-output* nil :prologue nil :indent > nil) > (:html > (:head > (:title "Test page")) > (:body > (:p "wei?"))))) > > Will produce text like "wei?" > If I set the global variable: > (setf *hunchentoot-default-external-format* (flex:make-external-format > :utf-8 :eol-style :lf)) > the problem gets fixed. > > Andrew > As a matter of interest, why do you have a problem using UTF8 everywhere? Just about everything supports it these days, and the lower seven bits look like ASCII? Anyway, (setf (reply-external-format &optional reply) new-value) with the make-external-format thing as 'new-value' should do the trick. Rob From lispercat at gmail.com Tue Sep 2 20:51:51 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Tue, 2 Sep 2008 16:51:51 -0400 Subject: [hunchentoot-devel] Re: utf-8 encoding problems In-Reply-To: <24f203480809021338o761c3ee2r1588eed12fda8db9@mail.gmail.com> References: <24f203480809021338o761c3ee2r1588eed12fda8db9@mail.gmail.com> Message-ID: Thanks, Robert, it works! The reason I don't use it globally is because in the system I have right now I pass a lot of textual data in the GET requests and for some reason it didn't work off the bat when I set that global variable (I'll look into it anyway). Andrew On Tue, Sep 2, 2008 at 4:38 PM, Robert Synnott wrote: > 2008/9/2 Andrei Stebakov : > > No luck emailing the quotation marks. Let's try a German character '?' > > > > (defun test-handler () > > (no-cache) > > (recompute-request-parameters :external-format > (flex:make-external-format > > :utf-8 :eol-style :lf)) > > (setf (hunchentoot:content-type) "text/html; charset=utf-8") > > (with-html-output-to-string (*standard-output* nil :prologue nil > :indent > > nil) > > (:html > > (:head > > (:title "Test page")) > > (:body > > (:p "wei?"))))) > > > > Will produce text like "wei?" > > If I set the global variable: > > (setf *hunchentoot-default-external-format* (flex:make-external-format > > :utf-8 :eol-style :lf)) > > the problem gets fixed. > > > > Andrew > > > > As a matter of interest, why do you have a problem using UTF8 > everywhere? Just about everything supports it these days, and the > lower seven bits look like ASCII? > > Anyway, (setf (reply-external-format &optional reply) new-value) with > the make-external-format thing as 'new-value' should do the trick. > Rob > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lispercat at gmail.com Tue Sep 2 21:48:00 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Tue, 2 Sep 2008 17:48:00 -0400 Subject: [hunchentoot-devel] Re: utf-8 encoding problems In-Reply-To: <24f203480809021338o761c3ee2r1588eed12fda8db9@mail.gmail.com> References: <24f203480809021338o761c3ee2r1588eed12fda8db9@mail.gmail.com> Message-ID: > > As a matter of interest, why do you have a problem using UTF8 > everywhere? Just about everything supports it these days, and the > lower seven bits look like ASCII? If I set global (setf *hunchentoot-default-external-format* (flex:make-external-format :utf-8 :eol-style :lf)) Then all my handlers which generate images will produce empty outputs. Andrew On Tue, Sep 2, 2008 at 4:38 PM, Robert Synnott wrote: > 2008/9/2 Andrei Stebakov : > > No luck emailing the quotation marks. Let's try a German character '?' > > > > (defun test-handler () > > (no-cache) > > (recompute-request-parameters :external-format > (flex:make-external-format > > :utf-8 :eol-style :lf)) > > (setf (hunchentoot:content-type) "text/html; charset=utf-8") > > (with-html-output-to-string (*standard-output* nil :prologue nil > :indent > > nil) > > (:html > > (:head > > (:title "Test page")) > > (:body > > (:p "wei?"))))) > > > > Will produce text like "wei?" > > If I set the global variable: > > (setf *hunchentoot-default-external-format* (flex:make-external-format > > :utf-8 :eol-style :lf)) > > the problem gets fixed. > > > > Andrew > > > > As a matter of interest, why do you have a problem using UTF8 > everywhere? Just about everything supports it these days, and the > lower seven bits look like ASCII? > > Anyway, (setf (reply-external-format &optional reply) new-value) with > the make-external-format thing as 'new-value' should do the trick. > Rob > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lispercat at gmail.com Tue Sep 2 22:27:16 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Tue, 2 Sep 2008 18:27:16 -0400 Subject: [hunchentoot-devel] url-decode with Unicode text Message-ID: Let's say I have some Greek text in the url, which is encoded in utf-8. The string is "????????". When the ht server receives the request with the string, it goes to url-decode with fails with the message: junk in string "%u03B5%u03BB%u03BB%u03B7%u03BD%u03B9%u03BA%u03AE" [Condition of type SB-INT:SIMPLE-PARSE-ERROR] It can be reproduced by evaluating: (HUNCHENTOOT:URL-DECODE "%u03B5%u03BB%u03BB%u03B7%u03BD%u03B9%u03BA%u03AE" (flex:make-external-format :utf-8 :eol-style :lf)) Backtrace: 0: (PARSE-INTEGER "%u03B5%u03BB%u03BB%u03B7%u03BD%u03B9%u03BA%u03AE")[:EXTERNAL] 1: (URL-DECODE "%u03B5%u03BB%u03BB%u03B7%u03BD%u03B9%u03BA%u03AE" #) How can I decode Greek (or any other for that matter) text? I took Greek as an example as Latin/German text worked. Thank you, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Wed Sep 3 06:42:14 2008 From: edi at agharta.de (Edi Weitz) Date: Wed, 03 Sep 2008 08:42:14 +0200 Subject: [hunchentoot-devel] Re: utf-8 encoding problems In-Reply-To: (Andrei Stebakov's message of "Tue, 2 Sep 2008 17:48:00 -0400") References: <24f203480809021338o761c3ee2r1588eed12fda8db9@mail.gmail.com> Message-ID: On Tue, 2 Sep 2008 17:48:00 -0400, "Andrei Stebakov" wrote: > If I set global (setf *hunchentoot-default-external-format* > (flex:make-external-format :utf-8 :eol-style :lf)) Then all my > handlers which generate images will produce empty outputs. How do your image handlers look like? They should return binary data and shouldn't be affected by the external format. From edi at agharta.de Wed Sep 3 06:50:12 2008 From: edi at agharta.de (Edi Weitz) Date: Wed, 03 Sep 2008 08:50:12 +0200 Subject: [hunchentoot-devel] url-decode with Unicode text In-Reply-To: (Andrei Stebakov's message of "Tue, 2 Sep 2008 18:27:16 -0400") References: Message-ID: On Tue, 2 Sep 2008 18:27:16 -0400, "Andrei Stebakov" wrote: > Let's say I have some Greek text in the url, which is encoded in > utf-8. The string is "????????". When the ht server receives the > request with the string, it goes to url-decode with fails with the > message: junk in string > "%u03B5%u03BB%u03BB%u03B7%u03BD%u03B9%u03BA%u03AE" That's a non-standard syntax which is not supported. http://en.wikipedia.org/wiki/Url_encoding#Non-standard_implementations From mail at chaitanyagupta.com Wed Sep 3 07:43:24 2008 From: mail at chaitanyagupta.com (Chaitanya Gupta) Date: Wed, 03 Sep 2008 13:13:24 +0530 Subject: [hunchentoot-devel] Request methods suffixed with * -- not backwards compatible? In-Reply-To: References: <48BA27A9.6020508@chaitanyagupta.com> <48BBE95C.90001@chaitanyagupta.com> <2079faf0809010921kbba2024w2570f1fe4d2407f6@mail.gmail.com> Message-ID: <48BE401C.7010500@chaitanyagupta.com> Edi Weitz wrote: > > We thought about this as well and eventually decided to go this way. > One of the goals of the new release is a clearer CLOS-based model of > the request/response phase and we think that the names should reflect > this. I'm usually trying to be as backwards-compatible as possible > (mind you, I have to update my web apps as well!), but sometimes it > simply isn't possible. > > So that's that then, which is fine. I still wish, though, that this didn't have to happen. :) Still, I can't really see what will be gained by exporting the request(or reply) accessors. If you can explain what you have in mind when you say a clearer CLOS-based model, and how it will help, that will be great. Cheers, Chaitanya From edi at agharta.de Wed Sep 3 07:51:59 2008 From: edi at agharta.de (Edi Weitz) Date: Wed, 03 Sep 2008 09:51:59 +0200 Subject: [hunchentoot-devel] Request methods suffixed with * -- not backwards compatible? In-Reply-To: <48BE401C.7010500@chaitanyagupta.com> (Chaitanya Gupta's message of "Wed, 03 Sep 2008 13:13:24 +0530") References: <48BA27A9.6020508@chaitanyagupta.com> <48BBE95C.90001@chaitanyagupta.com> <2079faf0809010921kbba2024w2570f1fe4d2407f6@mail.gmail.com> <48BE401C.7010500@chaitanyagupta.com> Message-ID: On Wed, 03 Sep 2008 13:13:24 +0530, Chaitanya Gupta wrote: > Still, I can't really see what will be gained by exporting the > request(or reply) accessors. If you can explain what you have in > mind when you say a clearer CLOS-based model, and how it will help, > that will be great. The idea is that all the relevant objects (request, replies, servers) are CLOS objects (which is already the case) and exported (which isn't the case now) so that you can subclass them and write your own methods which override the default behaviour. This is not possible with functions like, say, the current REQUEST-METHOD that only have optional parameters. In the future, REQUEST-METHOD (with a required parameter) will be a generic function while REQUEST-METHOD* (with an optional parameter like now) will just be a "convenience layer", if you so will. We thought about naming the generic function REQUEST-REQUEST-METHOD or something like that, but all the alternatives we came up with sounded dumb. I think it's better to use the "real" names (the ones derived from the RFCs or legacy usage) for the "real" functions. Edi. From hans at huebner.org Wed Sep 3 08:03:40 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 3 Sep 2008 10:03:40 +0200 Subject: [hunchentoot-devel] Request methods suffixed with * -- not backwards compatible? In-Reply-To: References: <48BA27A9.6020508@chaitanyagupta.com> <48BBE95C.90001@chaitanyagupta.com> <2079faf0809010921kbba2024w2570f1fe4d2407f6@mail.gmail.com> <48BE401C.7010500@chaitanyagupta.com> Message-ID: On Wed, Sep 3, 2008 at 09:51, Edi Weitz wrote: > The idea is that all the relevant objects (request, replies, servers) > are CLOS objects (which is already the case) and exported (which isn't > the case now) so that you can subclass them and write your own methods > which override the default behaviour. One example usage for this would be in a web framework that associates certain kinds of information (i.e. sessions, users, uploaded files) with a request earlier in the request processing chain. Currently, this can be done using the aux-request-value mechanism, but that is rather clumsy. -Hans From lispercat at gmail.com Wed Sep 3 14:10:32 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Wed, 3 Sep 2008 10:10:32 -0400 Subject: [hunchentoot-devel] Re: utf-8 encoding problems In-Reply-To: References: <24f203480809021338o761c3ee2r1588eed12fda8db9@mail.gmail.com> Message-ID: My image handlers look approximately like: (defun image-handler () (no-cache) (setf (hunchentoot:content-type) "image/jpeg") (let ((stream (send-headers))) (with-image (new 100 100) (do-something-with-img new) (write-jpeg-to-stream stream :image new)))) Andrew On Wed, Sep 3, 2008 at 2:42 AM, Edi Weitz wrote: > On Tue, 2 Sep 2008 17:48:00 -0400, "Andrei Stebakov" > wrote: > > > If I set global (setf *hunchentoot-default-external-format* > > (flex:make-external-format :utf-8 :eol-style :lf)) Then all my > > handlers which generate images will produce empty outputs. > > How do your image handlers look like? They should return binary data > and shouldn't be affected by the external format. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lispercat at gmail.com Wed Sep 3 14:13:52 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Wed, 3 Sep 2008 10:13:52 -0400 Subject: [hunchentoot-devel] url-decode with Unicode text In-Reply-To: References: Message-ID: But both IE and FF send this kind of encoding. Anything can be done to make them send the supported encoding? Thank you, Andrew On Wed, Sep 3, 2008 at 2:50 AM, Edi Weitz wrote: > On Tue, 2 Sep 2008 18:27:16 -0400, "Andrei Stebakov" > wrote: > > > Let's say I have some Greek text in the url, which is encoded in > > utf-8. The string is "????????". When the ht server receives the > > request with the string, it goes to url-decode with fails with the > > message: junk in string > > "%u03B5%u03BB%u03BB%u03B7%u03BD%u03B9%u03BA%u03AE" > > That's a non-standard syntax which is not supported. > > http://en.wikipedia.org/wiki/Url_encoding#Non-standard_implementations > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Wed Sep 3 14:30:46 2008 From: edi at agharta.de (Edi Weitz) Date: Wed, 03 Sep 2008 16:30:46 +0200 Subject: [hunchentoot-devel] url-decode with Unicode text In-Reply-To: (Andrei Stebakov's message of "Wed, 3 Sep 2008 10:13:52 -0400") References: Message-ID: On Wed, 3 Sep 2008 10:13:52 -0400, "Andrei Stebakov" wrote: > But both IE and FF send this kind of encoding. When do they do that? From edi at agharta.de Wed Sep 3 14:34:53 2008 From: edi at agharta.de (Edi Weitz) Date: Wed, 03 Sep 2008 16:34:53 +0200 Subject: [hunchentoot-devel] Re: utf-8 encoding problems In-Reply-To: (Andrei Stebakov's message of "Wed, 3 Sep 2008 10:10:32 -0400") References: <24f203480809021338o761c3ee2r1588eed12fda8db9@mail.gmail.com> Message-ID: On Wed, 3 Sep 2008 10:10:32 -0400, "Andrei Stebakov" wrote: > My image handlers look approximately like: > > (defun image-handler () > (no-cache) > (setf (hunchentoot:content-type) "image/jpeg") > (let ((stream (send-headers))) > (with-image (new 100 100) > (do-something-with-img new) > (write-jpeg-to-stream stream :image new)))) You want to write binary data to this stream. See the sentence about "faithful output" here: http://weitz.de/cl-gd/#write-jpeg-to-stream Edi. From lispercat at gmail.com Wed Sep 3 15:40:32 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Wed, 3 Sep 2008 11:40:32 -0400 Subject: [hunchentoot-devel] url-decode with Unicode text In-Reply-To: References: Message-ID: They do it when I use JavaScript escape() function to encode some characters like #@, line feed, etc. If I don't use this function I lose those characters, but then I don't get the error message for the Greek or other languages (those characters are being displayed as question marks). On Wed, Sep 3, 2008 at 10:30 AM, Edi Weitz wrote: > On Wed, 3 Sep 2008 10:13:52 -0400, "Andrei Stebakov" > wrote: > > > But both IE and FF send this kind of encoding. > > When do they do that? > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at huebner.org Wed Sep 3 15:45:04 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 3 Sep 2008 17:45:04 +0200 Subject: [hunchentoot-devel] url-decode with Unicode text In-Reply-To: References: Message-ID: I would be in favour of supporting the non-standard behavior and will come up with a patch to try, hoping that Edi accepts it. -Hans On Wed, Sep 3, 2008 at 17:40, Andrei Stebakov wrote: > They do it when I use JavaScript escape() function to encode some characters > like #@, line feed, etc. > If I don't use this function I lose those characters, but then I don't get > the error message for the Greek or other languages (those characters are > being displayed as question marks). > > > > On Wed, Sep 3, 2008 at 10:30 AM, Edi Weitz wrote: >> >> On Wed, 3 Sep 2008 10:13:52 -0400, "Andrei Stebakov" >> wrote: >> >> > But both IE and FF send this kind of encoding. >> >> When do they do that? >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From lispercat at gmail.com Wed Sep 3 16:05:03 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Wed, 3 Sep 2008 12:05:03 -0400 Subject: [hunchentoot-devel] Re: utf-8 encoding problems In-Reply-To: References: <24f203480809021338o761c3ee2r1588eed12fda8db9@mail.gmail.com> Message-ID: Does it mean that I need to get the underlying binary stream from the flexi stream returned by (send-headers) and use it with write-jpeg-to-stream? Or use some other function (not write-jpeg-to-stream) so it returns an array of octets instead of writing to the stream? Andrew On Wed, Sep 3, 2008 at 10:34 AM, Edi Weitz wrote: > On Wed, 3 Sep 2008 10:10:32 -0400, "Andrei Stebakov" > wrote: > > > My image handlers look approximately like: > > > > (defun image-handler () > > (no-cache) > > (setf (hunchentoot:content-type) "image/jpeg") > > (let ((stream (send-headers))) > > (with-image (new 100 100) > > (do-something-with-img new) > > (write-jpeg-to-stream stream :image new)))) > > You want to write binary data to this stream. See the sentence about > "faithful output" here: > > http://weitz.de/cl-gd/#write-jpeg-to-stream > > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Wed Sep 3 16:07:05 2008 From: edi at agharta.de (Edi Weitz) Date: Wed, 03 Sep 2008 18:07:05 +0200 Subject: [hunchentoot-devel] url-decode with Unicode text In-Reply-To: (Andrei Stebakov's message of "Wed, 3 Sep 2008 11:40:32 -0400") References: Message-ID: On Wed, 3 Sep 2008 11:40:32 -0400, "Andrei Stebakov" wrote: > They do it when I use JavaScript escape() function See the link I sent earlier. From lispercat at gmail.com Wed Sep 3 16:11:33 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Wed, 3 Sep 2008 12:11:33 -0400 Subject: [hunchentoot-devel] url-decode with Unicode text In-Reply-To: References: Message-ID: Oh, you mean using JS urlEncode and then use HT url-decode? I'll try it.** On Wed, Sep 3, 2008 at 12:07 PM, Edi Weitz wrote: > On Wed, 3 Sep 2008 11:40:32 -0400, "Andrei Stebakov" > wrote: > > > They do it when I use JavaScript escape() function > > See the link I sent earlier. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at chaitanyagupta.com Wed Sep 3 16:19:45 2008 From: mail at chaitanyagupta.com (Chaitanya Gupta) Date: Wed, 03 Sep 2008 21:49:45 +0530 Subject: [hunchentoot-devel] Request methods suffixed with * -- not backwards compatible? In-Reply-To: References: <48BA27A9.6020508@chaitanyagupta.com> <48BBE95C.90001@chaitanyagupta.com> <2079faf0809010921kbba2024w2570f1fe4d2407f6@mail.gmail.com> <48BE401C.7010500@chaitanyagupta.com> Message-ID: <48BEB921.9050603@chaitanyagupta.com> Edi Weitz wrote: > > The idea is that all the relevant objects (request, replies, servers) > are CLOS objects (which is already the case) and exported (which isn't > the case now) so that you can subclass them and write your own methods > which override the default behaviour. This is not possible with > functions like, say, the current REQUEST-METHOD that only have > optional parameters. In the future, REQUEST-METHOD (with a required > parameter) will be a generic function while REQUEST-METHOD* (with an > optional parameter like now) will just be a "convenience layer", if > you so will. That makes things a little clearer. Thanks. I'll be looking forward to how this turns out. Cheers, Chaitanya From lispercat at gmail.com Wed Sep 3 16:37:16 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Wed, 3 Sep 2008 12:37:16 -0400 Subject: [hunchentoot-devel] url-decode with Unicode text In-Reply-To: References: Message-ID: Well, encodeURIComponent used for text only part solves the non-standard language problem (strange characters, but no lisp exception), but it messes up some characters which are handled properly by escape() function (i.e "Ciar?n" is handled by escape() but not encodeURIComponent()). Andrew On Wed, Sep 3, 2008 at 12:11 PM, Andrei Stebakov wrote: > Oh, you mean using JS urlEncode and then use HT url-decode? I'll try it. > ** > > On Wed, Sep 3, 2008 at 12:07 PM, Edi Weitz wrote: > >> On Wed, 3 Sep 2008 11:40:32 -0400, "Andrei Stebakov" >> wrote: >> >> > They do it when I use JavaScript escape() function >> >> See the link I sent earlier. >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Wed Sep 3 17:56:16 2008 From: edi at agharta.de (Edi Weitz) Date: Wed, 03 Sep 2008 19:56:16 +0200 Subject: [hunchentoot-devel] Re: utf-8 encoding problems In-Reply-To: (Andrei Stebakov's message of "Wed, 3 Sep 2008 12:05:03 -0400") References: <24f203480809021338o761c3ee2r1588eed12fda8db9@mail.gmail.com> Message-ID: On Wed, 3 Sep 2008 12:05:03 -0400, "Andrei Stebakov" wrote: > Does it mean that I need to get the underlying binary stream from > the flexi stream returned by (send-headers) and use it with > write-jpeg-to-stream? Or use some other function (not > write-jpeg-to-stream) so it returns an array of octets instead of > writing to the stream? All of these should work (I think): - get the underlying stream - set the element type of the (flexi) stream to 'flex:octet - set the external format of the (flexi) stream to latin-1, or - return an array of octets. If you're not on CLISP, you should also be able to write binary data directly to the stream, but CL-GD won't do that (as it predates flexi-streams). From edi at agharta.de Wed Sep 3 17:57:51 2008 From: edi at agharta.de (Edi Weitz) Date: Wed, 03 Sep 2008 19:57:51 +0200 Subject: [hunchentoot-devel] url-decode with Unicode text In-Reply-To: (Andrei Stebakov's message of "Wed, 3 Sep 2008 12:37:16 -0400") References: Message-ID: On Wed, 3 Sep 2008 12:37:16 -0400, "Andrei Stebakov" wrote: > Well, encodeURIComponent used for text only part solves the > non-standard language problem (strange characters, but no lisp > exception), but it messes up some characters which are handled > properly by escape() function (i.e "Ciar?n" is handled by escape() > but not encodeURIComponent()). The Wiki page mentioned a function called encodeURI. That's not there? From lispercat at gmail.com Wed Sep 3 18:32:51 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Wed, 3 Sep 2008 14:32:51 -0400 Subject: [hunchentoot-devel] url-decode with Unicode text In-Reply-To: References: Message-ID: Yes, it's there, I tried it but for some reason I get an exception on lisp side when the whole URI is encoded. Then I started to use encodeURIComponent() with which I only encode the text part of the GET request. This works, only it messes up some of the non-standard characters. On Wed, Sep 3, 2008 at 1:57 PM, Edi Weitz wrote: > On Wed, 3 Sep 2008 12:37:16 -0400, "Andrei Stebakov" > wrote: > > > Well, encodeURIComponent used for text only part solves the > > non-standard language problem (strange characters, but no lisp > > exception), but it messes up some characters which are handled > > properly by escape() function (i.e "Ciar?n" is handled by escape() > > but not encodeURIComponent()). > > The Wiki page mentioned a function called encodeURI. That's not > there? > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From avodonosov at yandex.ru Wed Sep 3 20:32:38 2008 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Wed, 3 Sep 2008 23:32:38 +0300 Subject: [hunchentoot-devel] thread safety in session-value Message-ID: <1163407867.20080903233238@yandex.ru> Hello. Just noticed in the sources that SESSION-VALUE code does not have WITH-LOCK. IMHO it is necessary here. Best regards, -Anton From hans at huebner.org Wed Sep 3 20:51:25 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 3 Sep 2008 22:51:25 +0200 Subject: [hunchentoot-devel] thread safety in session-value In-Reply-To: <1163407867.20080903233238@yandex.ru> References: <1163407867.20080903233238@yandex.ru> Message-ID: On Wed, Sep 3, 2008 at 22:32, Anton Vodonosov wrote: > Just noticed in the sources that SESSION-VALUE > code does not have WITH-LOCK. IMHO it is necessary > here. Can you please be more specific? Thanks. -Hans From avodonosov at yandex.ru Wed Sep 3 21:22:23 2008 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Thu, 4 Sep 2008 00:22:23 +0300 Subject: [hunchentoot-devel] thread safety in session-value In-Reply-To: References: <1163407867.20080903233238@yandex.ru> Message-ID: <1493623457.20080904002223@yandex.ru> on Wednesday, September 3, 2008, 11:51:25 PM Hans wrote: > On Wed, Sep 3, 2008 at 22:32, Anton Vodonosov wrote: >> Just noticed in the sources that SESSION-VALUE >> code does not have WITH-LOCK. IMHO it is necessary >> here. > Can you please be more specific? Thanks. I thought that several functions work with the same list - SESSION-DATA slot of the session. For example if DELETE-SESSION-VALUE will happen in parallel with with (SESSION-VALUE ...) we will have ASSOC and DELETE on the same list simultaneously, which is IMHO unsafe. (SETF (SESSION-VALUE)..)) with (DELETE-SESSION-VALUE looks unsafe too: SETF does (push (slot-value ,%session 'session-data)) and in the same time in the DELETE-SESSION-VALUES (setf (slot-value session 'session-data). PUSH is not necessary atomic, IMHO; is it safe to use it in parallel with SETF? P.S. DELETE-SESSION-VALUE should use look too. - Anton From hans at huebner.org Thu Sep 4 04:47:38 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 4 Sep 2008 06:47:38 +0200 Subject: [hunchentoot-devel] thread safety in session-value In-Reply-To: <1493623457.20080904002223@yandex.ru> References: <1163407867.20080903233238@yandex.ru> <1493623457.20080904002223@yandex.ru> Message-ID: On Wed, Sep 3, 2008 at 23:22, Anton Vodonosov wrote: > on Wednesday, September 3, 2008, 11:51:25 PM Hans wrote: > >> On Wed, Sep 3, 2008 at 22:32, Anton Vodonosov wrote: >>> Just noticed in the sources that SESSION-VALUE >>> code does not have WITH-LOCK. IMHO it is necessary >>> here. > >> Can you please be more specific? Thanks. > > I thought that several functions work with the same list > - SESSION-DATA slot of the session. I agree, this could be a problem if one session is accessed by multiple requests, and this is not a completely unlikely scenario (although I have not been bitten by this). Do you have a patch? -Hans From hans at huebner.org Thu Sep 4 09:28:13 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 4 Sep 2008 11:28:13 +0200 Subject: [hunchentoot-devel] url-decode with Unicode text In-Reply-To: References: Message-ID: On Wed, Sep 3, 2008 at 17:45, Hans H?bner wrote: > I would be in favour of supporting the non-standard behavior and will > come up with a patch to try, hoping that Edi accepts it. I took this as an opportunity to work on overcoming my aversion against loop. Please see http://bknr.net/trac/changeset/3785 (http://bknr.net/trac/changeset/3785?format=diff&new=3785) for a patch. Let me know if it works for you. -Hans From hans at huebner.org Thu Sep 4 13:12:16 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 4 Sep 2008 15:12:16 +0200 Subject: [hunchentoot-devel] url-decode with Unicode text In-Reply-To: References: Message-ID: Kilian reported that URL-DECODE of an empty string did not work with my new implementation. Here is the corrected patch: http://bknr.net/trac/changeset?format=diff&new=3790&old=3784&new_path=trunk%2Fthirdparty%2Fhunchentoot%2Futil.lisp&old_path=trunk%2Fthirdparty%2Fhunchentoot%2Futil.lisp -Hans On Thu, Sep 4, 2008 at 11:28, Hans H?bner wrote: > On Wed, Sep 3, 2008 at 17:45, Hans H?bner wrote: >> I would be in favour of supporting the non-standard behavior and will >> come up with a patch to try, hoping that Edi accepts it. > > I took this as an opportunity to work on overcoming my aversion > against loop. Please see http://bknr.net/trac/changeset/3785 > (http://bknr.net/trac/changeset/3785?format=diff&new=3785) for a > patch. Let me know if it works for you. > > -Hans > From avodonosov at yandex.ru Thu Sep 4 18:12:01 2008 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Thu, 4 Sep 2008 21:12:01 +0300 Subject: [hunchentoot-devel] thread safety in session-value In-Reply-To: References: <1163407867.20080903233238@yandex.ru> <1493623457.20080904002223@yandex.ru> Message-ID: <11432988.20080904211201@yandex.ru> on Thursday, September 4, 2008, 7:47:38 AM Hans wrote: > On Wed, Sep 3, 2008 at 23:22, Anton Vodonosov wrote: >> on Wednesday, September 3, 2008, 11:51:25 PM Hans wrote: >> >>> On Wed, Sep 3, 2008 at 22:32, Anton Vodonosov wrote: >>>> Just noticed in the sources that SESSION-VALUE >>>> code does not have WITH-LOCK. IMHO it is necessary >>>> here. >> >>> Can you please be more specific? Thanks. >> >> I thought that several functions work with the same list >> - SESSION-DATA slot of the session. > I agree, this could be a problem if one session is accessed by > multiple requests, and this is not a completely unlikely scenario > (although I have not been bitten by this). Do you have a patch? No, sorry, I don't have a patch at the moment (if I had had it I would have posted it in the previous letter). Best regards, -Anton From lispercat at gmail.com Thu Sep 4 18:54:29 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Thu, 4 Sep 2008 14:54:29 -0400 Subject: [hunchentoot-devel] url-decode with Unicode text In-Reply-To: References: Message-ID: For hunchentoot-0.15.7 the patch is rejected. What version of hunchentoot this patch is for? Thank you, Andrew On Thu, Sep 4, 2008 at 9:12 AM, Hans H?bner wrote: > Kilian reported that URL-DECODE of an empty string did not work with > my new implementation. Here is the corrected patch: > > > http://bknr.net/trac/changeset?format=diff&new=3790&old=3784&new_path=trunk%2Fthirdparty%2Fhunchentoot%2Futil.lisp&old_path=trunk%2Fthirdparty%2Fhunchentoot%2Futil.lisp > > -Hans > > On Thu, Sep 4, 2008 at 11:28, Hans H?bner wrote: > > On Wed, Sep 3, 2008 at 17:45, Hans H?bner wrote: > >> I would be in favour of supporting the non-standard behavior and will > >> come up with a patch to try, hoping that Edi accepts it. > > > > I took this as an opportunity to work on overcoming my aversion > > against loop. Please see http://bknr.net/trac/changeset/3785 > > (http://bknr.net/trac/changeset/3785?format=diff&new=3785) for a > > patch. Let me know if it works for you. > > > > -Hans > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at huebner.org Thu Sep 4 19:10:29 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 4 Sep 2008 21:10:29 +0200 Subject: [hunchentoot-devel] url-decode with Unicode text In-Reply-To: References: Message-ID: On Thu, Sep 4, 2008 at 20:54, Andrei Stebakov wrote: > For hunchentoot-0.15.7 the patch is rejected. What version of hunchentoot > this patch is for? The patch is against the development version, but it should be manually appliable to the release version, too, as it only reimplements URL-DECODE. -Hans From lispercat at gmail.com Thu Sep 4 19:32:17 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Thu, 4 Sep 2008 15:32:17 -0400 Subject: [hunchentoot-devel] url-decode with Unicode text In-Reply-To: References: Message-ID: Yes, Hans, it works with the patch. It displays cubes instead of characters but I think it's because the fonts are not installed on the system. Much better than the crash I used to have! Thank you, Andrew On Thu, Sep 4, 2008 at 3:10 PM, Hans H?bner wrote: > On Thu, Sep 4, 2008 at 20:54, Andrei Stebakov wrote: > > For hunchentoot-0.15.7 the patch is rejected. What version of hunchentoot > > this patch is for? > > The patch is against the development version, but it should be > manually appliable to the release version, too, as it only > reimplements URL-DECODE. > > -Hans > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Thu Sep 4 19:37:39 2008 From: edi at agharta.de (Edi Weitz) Date: Thu, 04 Sep 2008 21:37:39 +0200 Subject: [hunchentoot-devel] thread safety in session-value In-Reply-To: (Hans =?iso-8859-1?q?H=FCbner's?= message of "Thu, 4 Sep 2008 06:47:38 +0200") References: <1163407867.20080903233238@yandex.ru> <1493623457.20080904002223@yandex.ru> Message-ID: On Thu, 4 Sep 2008 06:47:38 +0200, "Hans H?bner" wrote: > I agree, this could be a problem if one session is accessed by > multiple requests, and this is not a completely unlikely scenario > (although I have not been bitten by this). Do you have a patch? I don't think this needs a patch. There's a lock for the case that Hunchentoot accesses the global session database. If you (as a user) write an application where different handlers or different threads work on the same session object at the same time, then you know what you're doing and you should take care of locking (if needed) yourself. IMNSHO it is a bad decision to defensively wrap locks around everything that could in theory be accessed simultaneously. From avodonosov at yandex.ru Thu Sep 4 20:36:01 2008 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Thu, 4 Sep 2008 23:36:01 +0300 Subject: [hunchentoot-devel] thread safety in session-value In-Reply-To: References: <1163407867.20080903233238@yandex.ru> <1493623457.20080904002223@yandex.ru> Message-ID: <926054768.20080904233601@yandex.ru> on Thursday, September 4, 2008, 10:37:39 PM Edi wrote: > On Thu, 4 Sep 2008 06:47:38 +0200, "Hans H?bner" wrote: >> I agree, this could be a problem if one session is accessed by >> multiple requests, and this is not a completely unlikely scenario >> (although I have not been bitten by this). Do you have a patch? > I don't think this needs a patch. There's a lock for the case that > Hunchentoot accesses the global session database. If you (as a user) > write an application where different handlers or different threads > work on the same session object at the same time, then you know what > you're doing and you should take care of locking (if needed) yourself. > IMNSHO it is a bad decision to defensively wrap locks around > everything that could in theory be accessed simultaneously. Yes, such a contract may be used too, although in this case it looks to me that user must take care of locking in virtually 100% of cases - even single handler may be called from different threads for the same session. And btw this is unexpected clarification to session functions behavior, at least for me. In fact my attention to this question was drawn by the fact that (SETF (SESSION-VALUE )) uses lock, but other functions do not. And the condition that aimed to be protected by the lock in (SETF (SESSION-VALUE )) may potentially be broken by concurrent DELETE-SESSION-VALUE. Best regards, -Anton P.S. If you wonder why am I poking in the hunchentoot code - I am studying how session keys are generated in hope to find an example of secure random value generation to use it in cl-openid. From edi at agharta.de Thu Sep 4 21:14:59 2008 From: edi at agharta.de (Edi Weitz) Date: Thu, 04 Sep 2008 23:14:59 +0200 Subject: [hunchentoot-devel] thread safety in session-value In-Reply-To: <926054768.20080904233601@yandex.ru> (Anton Vodonosov's message of "Thu, 4 Sep 2008 23:36:01 +0300") References: <1163407867.20080903233238@yandex.ru> <1493623457.20080904002223@yandex.ru> <926054768.20080904233601@yandex.ru> Message-ID: On Thu, 4 Sep 2008 23:36:01 +0300, Anton Vodonosov wrote: > Yes, such a contract may be used too, although in this case it looks > to me that user must take care of locking in virtually 100% of cases > - even single handler may be called from different threads for the > same session. Yes, you're right. I never had problems with this so far, but maybe this is because I've rarely used Hunchentoot with SMP Lisps. In this case, you don't want to use a global lock, though, and I wonder how expensive it is to have one lock per session. I have to think about this a bit... > In fact my attention to this question was drawn by the fact that > (SETF (SESSION-VALUE )) uses lock, but other functions do not. The lock in (SETF SESSION-VALUE) is clearly unneeded as START-SESSION already has a lock. As the name says, *SESSION-DATA-LOCK* was only meant to protect *SESSION-DATA*. > If you wonder why am I poking in the hunchentoot code Oh, that's fine. Feel free to poke around and find more bugs... :) From avodonosov at yandex.ru Thu Sep 4 22:46:48 2008 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Fri, 5 Sep 2008 01:46:48 +0300 Subject: [hunchentoot-devel] thread safety in session-value In-Reply-To: References: <1163407867.20080903233238@yandex.ru> <1493623457.20080904002223@yandex.ru> <926054768.20080904233601@yandex.ru> Message-ID: <607604154.20080905014648@yandex.ru> on Friday, September 5, 2008, 12:14:59 AM Edi wrote: > In this case, you don't want to use a global lock, though, and I > wonder how expensive it is to have one lock per session. I have to > think about this a bit... One per session is better IMO; lock in the worst case is several bytes + maybe a string if you will provide a name - quite cheap. Best regards, -Anton From lispercat at gmail.com Sat Sep 13 22:55:46 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Sat, 13 Sep 2008 18:55:46 -0400 Subject: [hunchentoot-devel] Preventing users to upload too big files Message-ID: I wonder what's the best way to handle the case when a user tries to upload a very large file. Basically we need to stop execution before it gets to the parse-rfc2388-form-data and report the problem to the user. I can think of placing some function call inside request's constructor (defmethod initialize-instance :after ((request request) &rest init-args) Something like: (let* ((check (find-symbol "CHECK-FILE-SIZE" :your-package)) (header-value (find-symbol "HEADER-VALUE" :drakma)) (length (parse-integer (funcall header-value :content-length headers-in)))) (funcall check length)) Inside function check-file-size you would raise an error if the file is too big. The problem is that this error gets handled by the lisp debugger and I can't propagate it to the user. Another thing, it's a dirty hack, what's the better way of doing this? Thank you, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at huebner.org Sun Sep 14 07:14:36 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun, 14 Sep 2008 09:14:36 +0200 Subject: [hunchentoot-devel] Preventing users to upload too big files In-Reply-To: References: Message-ID: On Sun, Sep 14, 2008 at 00:55, Andrei Stebakov wrote: > I wonder what's the best way to handle the case when a user tries to upload > a very large file. > Basically we need to stop execution before it gets to the > parse-rfc2388-form-data and report the problem to the user. >[...] > Another thing, it's a dirty hack, what's the better way of doing this? I would fix the problem in RFC2388:READ-UNTIL-NEXT-BOUNDARY. This function should read the data directly to the stream provided, and it should have a special variable (in the RFC2388 package) that can be set to limit the maximum number of bytes read. -Hans From lispercat at gmail.com Sun Sep 14 13:21:41 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Sun, 14 Sep 2008 09:21:41 -0400 Subject: [hunchentoot-devel] Preventing users to upload too big files In-Reply-To: References: Message-ID: The problem is that RFC2388:READ-UNTIL-NEXT-BOUNDARY doesn't know about the content-length as hunchentoot package doesn't pass this parameter to the rfc2388:parse-mime function. So again it should be changed in two different packages. When I implemented file upload progress bar, I had to modify the hunchentoot and rfc2388 since only hunchentoot knows about content-length and only rfc2388 knows how many bytes was read from the stream. Using these two parameters we can calculate the percentage of the data that was uploaded to the server. I could retrieve the content-length to the client via ajax and do something in javascript to disrupt the upload, but I doesn't look like a good solution to me. So, my question is where and how in hunchentoot I can raise an error so that it would get propagated to the handler of the file upload request so that I can show it to the user. In the request constructor (defmethod initialize-instance ...) the body is wrapped into handler-case so any error which occurs in it should be trapped by (error (cond) ...), right? For some reason the error that I raise when the content-length is greater than some number, this error gets trapped by the lisp debugger, not by (error (cond) ...). Anyway, time for me to go back study lisp manuals! :) Andrew On Sun, Sep 14, 2008 at 3:14 AM, Hans H?bner wrote: > On Sun, Sep 14, 2008 at 00:55, Andrei Stebakov > wrote: > > I wonder what's the best way to handle the case when a user tries to > upload > > a very large file. > > Basically we need to stop execution before it gets to the > > parse-rfc2388-form-data and report the problem to the user. > >[...] > > Another thing, it's a dirty hack, what's the better way of doing this? > > I would fix the problem in RFC2388:READ-UNTIL-NEXT-BOUNDARY. This > function should read the data directly to the stream provided, and it > should have a special variable (in the RFC2388 package) that can be > set to limit the maximum number of bytes read. > > -Hans > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From public.avatar at gmail.com Fri Sep 19 07:35:50 2008 From: public.avatar at gmail.com (AvataR) Date: Fri, 19 Sep 2008 10:35:50 +0300 Subject: [hunchentoot-devel] Hunchentoot and raw data output Message-ID: <878wtoy4dl.fsf@gmail.com> Hi! How can I output data without a headers? I try to use external CSS, but hunchentoot add a header to CSS data. From edi at agharta.de Fri Sep 19 07:43:21 2008 From: edi at agharta.de (Edi Weitz) Date: Fri, 19 Sep 2008 09:43:21 +0200 Subject: [hunchentoot-devel] Hunchentoot and raw data output In-Reply-To: <878wtoy4dl.fsf@gmail.com> (AvataR's message of "Fri, 19 Sep 2008 10:35:50 +0300") References: <878wtoy4dl.fsf@gmail.com> Message-ID: On Fri, 19 Sep 2008 10:35:50 +0300, public.avatar at gmail.com ([AvataR]) wrote: > How can I output data without a headers? I try to use external CSS, > but hunchentoot add a header to CSS data. Which header are you trying to get rid of in particular? From public.avatar at gmail.com Fri Sep 19 08:00:16 2008 From: public.avatar at gmail.com (AvataR) Date: Fri, 19 Sep 2008 11:00:16 +0300 Subject: [hunchentoot-devel] Hunchentoot and raw data output In-Reply-To: (Edi Weitz's message of "Fri, 19 Sep 2008 09:43:21 +0200") References: <878wtoy4dl.fsf@gmail.com> Message-ID: <871vzgy38v.fsf@gmail.com> Mm.. Must be (example from server with external CSS, i request CSS manualy): avatar at Nemesis ~ % telnet habrahabr.ru 80 | head Trying 62.213.122.2... Connected to habrahabr.ru. Escape character is '^]'. GET /css/main.css body, html { height: 100%; } body { font: .75em Verdana, sans-serif; /*12px is font-size for main content. Base font size*/ color:#000; background:#fff; ^CConnection closed by foreign host. And by hunchentoot: avatar at Nemesis ~ % telnet 10.0.1.12 8000 | head -n 20 Trying 10.0.1.12... Connected to 10.0.1.12. Escape character is '^]'. GET /index.css Connection closed by foreign host. HTTP/1.1 200 OK Content-Length: 310 Content-Type: text/html; charset=iso-8859-1 Date: Fri, 19 Sep 2008 07:58:23 GMT Server: Hunchentoot 0.15.7 Connection: Close #header { text-align: center; float: top; color: 0x0000FF; } #sidebar { text-align: center; float: left; I.e. all headers must be turned off From edi at agharta.de Fri Sep 19 08:13:16 2008 From: edi at agharta.de (Edi Weitz) Date: Fri, 19 Sep 2008 10:13:16 +0200 Subject: [hunchentoot-devel] Hunchentoot and raw data output In-Reply-To: <871vzgy38v.fsf@gmail.com> (AvataR's message of "Fri, 19 Sep 2008 11:00:16 +0300") References: <878wtoy4dl.fsf@gmail.com> <871vzgy38v.fsf@gmail.com> Message-ID: On Fri, 19 Sep 2008 11:00:16 +0300, public.avatar at gmail.com ([AvataR]) wrote: > Must be (example from server with external CSS, i request CSS > manualy): > > avatar at Nemesis ~ % telnet habrahabr.ru 80 | head > Trying 62.213.122.2... > Connected to habrahabr.ru. > Escape character is '^]'. > GET /css/main.css > body, html { > height: 100%; > } > body { > font: .75em Verdana, sans-serif; /*12px is font-size for main content. Base font size*/ > color:#000; > background:#fff; > ^CConnection closed by foreign host. > > And by hunchentoot: > > avatar at Nemesis ~ % telnet 10.0.1.12 8000 | head -n 20 > Trying 10.0.1.12... > Connected to 10.0.1.12. > Escape character is '^]'. > GET /index.css > Connection closed by foreign host. > HTTP/1.1 200 OK > Content-Length: 310 > Content-Type: text/html; charset=iso-8859-1 > Date: Fri, 19 Sep 2008 07:58:23 GMT > Server: Hunchentoot 0.15.7 > Connection: Close > > #header { > text-align: center; > float: top; > color: 0x0000FF; > } > > #sidebar { > text-align: center; > float: left; > > I.e. all headers must be turned off Yes, in the case of HTTP/0.9 Hunchentoot should send no headers at all although it does. I've seen no pressing need so far to support HTTP/0.9, but if someone wants to send a patch (against the dev version, please), I'll be happy to integrate it. http://weitz.de/patches.html Why do you need HTTP/0.9 support? From hans at huebner.org Fri Sep 19 08:13:38 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 19 Sep 2008 10:13:38 +0200 Subject: [hunchentoot-devel] Hunchentoot and raw data output In-Reply-To: <871vzgy38v.fsf@gmail.com> References: <878wtoy4dl.fsf@gmail.com> <871vzgy38v.fsf@gmail.com> Message-ID: On Fri, Sep 19, 2008 at 10:00, [AvataR] wrote: > Mm.. > Must be (example from server with external CSS, i request CSS manualy): > > avatar at Nemesis ~ % telnet habrahabr.ru 80 | head > Trying 62.213.122.2... > Connected to habrahabr.ru. > Escape character is '^]'. > GET /css/main.css > body, html { [...] This server is not following the requirements of the HTTP protocol. Hunchentoot does the right thing. Why do you think that Hunchentoot is wrong? -Hans From public.avatar at gmail.com Fri Sep 19 08:25:20 2008 From: public.avatar at gmail.com (AvataR) Date: Fri, 19 Sep 2008 11:25:20 +0300 Subject: [hunchentoot-devel] Hunchentoot and raw data output In-Reply-To: ("Hans =?utf-8?Q?H=C3=BCbner=22's?= message of "Fri, 19 Sep 2008 10:13:38 +0200") References: <878wtoy4dl.fsf@gmail.com> <871vzgy38v.fsf@gmail.com> Message-ID: <87wsh8wnin.fsf@gmail.com> Hm. I just got some unknown problem with including external css styles, and thought that this situation was a root of problem.. From hans at huebner.org Fri Sep 19 08:50:08 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 19 Sep 2008 10:50:08 +0200 Subject: [hunchentoot-devel] Hunchentoot and raw data output In-Reply-To: <87wsh8wnin.fsf@gmail.com> References: <878wtoy4dl.fsf@gmail.com> <871vzgy38v.fsf@gmail.com> <87wsh8wnin.fsf@gmail.com> Message-ID: Just to clear up things, and after having talked to Edi: If you use a HTTP/1.0 request, as in GET /css/main.css HTTP/1.0 I am pretty confident that your reference server will send headers just like Hunchentoot does. Try setting the HUNCHENTOOT:*HEADER-STREAM* variable to *STANDARD-OUTPUT* to see the headers exchanged between the browser and the client. That may help you understand what's going wrong. You may also find the Live HTTP Headers (https://addons.mozilla.org/de/firefox/addon/3829) extension for Firefox helpful. It does the same thing as HUNCHENTOOT:*HEADER-STREAM* for Firefox and can be very helpful to understand the interactions between the Browser and the HTTP server. -Hans On Fri, Sep 19, 2008 at 10:25, [AvataR] wrote: > Hm. I just got some unknown problem with including external css styles, > and thought that this situation was a root of problem.. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From hans at huebner.org Fri Sep 19 08:53:28 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 19 Sep 2008 10:53:28 +0200 Subject: [hunchentoot-devel] Preventing users to upload too big files In-Reply-To: References: Message-ID: After some internal discussion, I would recommend against hacking RFC2388 - It will most likely be replaced by something which is more extensible in the future. For the time being, your easiest solution might be to use the position counter of the flexi-stream that the upload is being read from. At the beginning of the request, you would make this stream accessible to your status handler (for example by putting it into the session), and the status handler would use the start and current position to measure request progress. Hope this still helps. Let us know if it works or if you have found another, better solution. -Hans On Sun, Sep 14, 2008 at 15:21, Andrei Stebakov wrote: > The problem is that RFC2388:READ-UNTIL-NEXT-BOUNDARY doesn't know about the > content-length as hunchentoot package doesn't pass this parameter to the > rfc2388:parse-mime function. So again it should be changed in two different > packages. > When I implemented file upload progress bar, I had to modify the hunchentoot > and rfc2388 since only hunchentoot knows about content-length and only > rfc2388 knows how many bytes was read from the stream. Using these two > parameters we can calculate the percentage of the data that was uploaded to > the server. > I could retrieve the content-length to the client via ajax and do something > in javascript to disrupt the upload, but I doesn't look like a good solution > to me. > So, my question is where and how in hunchentoot I can raise an error so that > it would get propagated to the handler of the file upload request so that I > can show it to the user. In the request constructor (defmethod > initialize-instance ...) the body is wrapped into handler-case so any error > which occurs in it should be trapped by (error (cond) ...), right? For some > reason the error that I raise when the content-length is greater than some > number, this error gets trapped by the lisp debugger, not by (error (cond) > ...). Anyway, time for me to go back study lisp manuals! :) > > Andrew > > On Sun, Sep 14, 2008 at 3:14 AM, Hans H?bner wrote: >> >> On Sun, Sep 14, 2008 at 00:55, Andrei Stebakov >> wrote: >> > I wonder what's the best way to handle the case when a user tries to >> > upload >> > a very large file. >> > Basically we need to stop execution before it gets to the >> > parse-rfc2388-form-data and report the problem to the user. >> >[...] >> > Another thing, it's a dirty hack, what's the better way of doing this? >> >> I would fix the problem in RFC2388:READ-UNTIL-NEXT-BOUNDARY. This >> function should read the data directly to the stream provided, and it >> should have a special variable (in the RFC2388 package) that can be >> set to limit the maximum number of bytes read. >> >> -Hans >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From public.avatar at gmail.com Fri Sep 19 09:22:35 2008 From: public.avatar at gmail.com (AvataR) Date: Fri, 19 Sep 2008 12:22:35 +0300 Subject: [hunchentoot-devel] Hunchentoot and raw data output In-Reply-To: ("Hans =?utf-8?Q?H=C3=BCbner=22's?= message of "Fri, 19 Sep 2008 10:50:08 +0200") References: <878wtoy4dl.fsf@gmail.com> <871vzgy38v.fsf@gmail.com> <87wsh8wnin.fsf@gmail.com> Message-ID: <87skrwwkv8.fsf@gmail.com> Thanks for help. Content-type was incorrect From lispercat at gmail.com Fri Sep 19 14:28:14 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Fri, 19 Sep 2008 10:28:14 -0400 Subject: [hunchentoot-devel] Preventing users to upload too big files In-Reply-To: References: Message-ID: Still, I have to put some hack inside the request constructor as it knows the content-length of the file being uploaded. Also the flexi-stream could be obtained from the constructor of request via (content-stream *request*). So, yes, this task could be minimized to hacking only one place in initialize-instance of request class. I'll try it. Thank you, Andrew On Fri, Sep 19, 2008 at 4:53 AM, Hans H?bner wrote: > After some internal discussion, I would recommend against hacking > RFC2388 - It will most likely be replaced by something which is more > extensible in the future. > > For the time being, your easiest solution might be to use the position > counter of the flexi-stream that the upload is being read from. At > the beginning of the request, you would make this stream accessible to > your status handler (for example by putting it into the session), and > the status handler would use the start and current position to measure > request progress. > > Hope this still helps. Let us know if it works or if you have found > another, better solution. > > -Hans > > On Sun, Sep 14, 2008 at 15:21, Andrei Stebakov > wrote: > > The problem is that RFC2388:READ-UNTIL-NEXT-BOUNDARY doesn't know about > the > > content-length as hunchentoot package doesn't pass this parameter to the > > rfc2388:parse-mime function. So again it should be changed in two > different > > packages. > > When I implemented file upload progress bar, I had to modify the > hunchentoot > > and rfc2388 since only hunchentoot knows about content-length and only > > rfc2388 knows how many bytes was read from the stream. Using these two > > parameters we can calculate the percentage of the data that was uploaded > to > > the server. > > I could retrieve the content-length to the client via ajax and do > something > > in javascript to disrupt the upload, but I doesn't look like a good > solution > > to me. > > So, my question is where and how in hunchentoot I can raise an error so > that > > it would get propagated to the handler of the file upload request so that > I > > can show it to the user. In the request constructor (defmethod > > initialize-instance ...) the body is wrapped into handler-case so any > error > > which occurs in it should be trapped by (error (cond) ...), right? For > some > > reason the error that I raise when the content-length is greater than > some > > number, this error gets trapped by the lisp debugger, not by (error > (cond) > > ...). Anyway, time for me to go back study lisp manuals! :) > > > > Andrew > > > > On Sun, Sep 14, 2008 at 3:14 AM, Hans H?bner wrote: > >> > >> On Sun, Sep 14, 2008 at 00:55, Andrei Stebakov > >> wrote: > >> > I wonder what's the best way to handle the case when a user tries to > >> > upload > >> > a very large file. > >> > Basically we need to stop execution before it gets to the > >> > parse-rfc2388-form-data and report the problem to the user. > >> >[...] > >> > Another thing, it's a dirty hack, what's the better way of doing this? > >> > >> I would fix the problem in RFC2388:READ-UNTIL-NEXT-BOUNDARY. This > >> function should read the data directly to the stream provided, and it > >> should have a special variable (in the RFC2388 package) that can be > >> set to limit the maximum number of bytes read. > >> > >> -Hans > >> _______________________________________________ > >> tbnl-devel site list > >> tbnl-devel at common-lisp.net > >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan.emrys at gmail.com Mon Sep 22 21:33:30 2008 From: bryan.emrys at gmail.com (Bryan Emrys) Date: Mon, 22 Sep 2008 14:33:30 -0700 Subject: [hunchentoot-devel] Why override the standard dispatcher? Message-ID: Newbie question. Can anyone explain why people would want to override the standard dispatcher? E.g. in http://www.lispcast.com/files/episode3/reddit-lisp.lisp (defclass handler () ((url :initarg :url :accessor url :type string) (handler :initarg :handler :accessor handler) (name :initarg :name :accessor name :type symbol))) (defvar *handlers* (make-hash-table)) (defun our-handler (request) (let ((handler (gethandler (hunchentoot:script-name request)))) (when handler (handler handler)))) (setf hunchentoot:*dispatch-table* (list 'our-handler)) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at huebner.org Mon Sep 22 22:25:52 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 22 Sep 2008 23:25:52 +0100 Subject: [hunchentoot-devel] Why override the standard dispatcher? In-Reply-To: References: Message-ID: On Mon, Sep 22, 2008 at 22:33, Bryan Emrys wrote: > Newbie question. Can anyone explain why people would want to override the > standard dispatcher? E.g. in > http://www.lispcast.com/files/episode3/reddit-lisp.lisp > > (defclass handler () > ((url > :initarg :url > :accessor url > :type string) > (handler > :initarg :handler > :accessor handler) > (name > :initarg :name > :accessor name > > :type symbol))) > > (defvar *handlers* (make-hash-table)) > > (defun our-handler (request) > (let ((handler (gethandler (hunchentoot:script-name request)))) > (when handler (handler handler)))) > > (setf hunchentoot:*dispatch-table* (list 'our-handler)) I personally find Hunchentoot's default handler architecture hard to work with. To me, a simple mapper from a URL prefix to a handler function is much easier to understand. That is why I have a request dispatch mechanism similar to the one you've reproduced in my web framework. -Hans