From neuss at kit.edu Thu Oct 7 11:35:38 2010 From: neuss at kit.edu (Nicolas Neuss) Date: Thu, 07 Oct 2010 13:35:38 +0200 Subject: [hunchentoot-devel] Encoding problem Message-ID: <87vd5exmk5.fsf@ma-patru.mathematik.uni-karlsruhe.de> Hello, I am trying to make Shibboleth authentification work for an application of mine. For this I am using the Apache2 Shibboleth module (my server sits behind Apache). Everything works fine, but for one thing. The authentification data is passed in the headers section in UTF-8 format (probably). What I receive using (CDR (ASSOC :SN (HEADERS-IN*))) in my server is wrong, namely my lastname which is correctly spelled "Neu?" (a German sharp-s) is read as "Neu??" which looks as if UTF-8 is read as LATIN-1. I don't quite know how this arises. I have SB-IMPL::*DEFAULT-EXTERNAL-FORMAT* = :UTF-8 HUNCHENTOOT:*HUNCHENTOOT-DEFAULT-EXTERNAL-FORMAT* = # Can anyone give me a hint what I could try? Thank you, Nicolas P.S.: I am using Hunchentoot-1.1.0/SBCL 1.0.18 on this machine. From hans.huebner at gmail.com Thu Oct 7 12:23:07 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 7 Oct 2010 14:23:07 +0200 Subject: [hunchentoot-devel] Encoding problem In-Reply-To: <87vd5exmk5.fsf@ma-patru.mathematik.uni-karlsruhe.de> References: <87vd5exmk5.fsf@ma-patru.mathematik.uni-karlsruhe.de> Message-ID: Hi Nicolas, On Thu, Oct 7, 2010 at 13:35, Nicolas Neuss wrote: > I am trying to make Shibboleth authentification work for an application > of mine. ?For this I am using the Apache2 Shibboleth module (my server > sits behind Apache). ?Everything works fine, but for one thing. ?The > authentification data is passed in the headers section in UTF-8 format > (probably). Before going into any depth on this, can you have a look at the headers and find out in what character set they are encoded? HTTP headers must be encoded as ISO-8859-1. If a client wants to send data in different encoding, quoted-printable encoding as described in RFC 2047 must be used. Thus, it would be a client error if you saw UTF-8 encoded data in headers. If the data is properly encoded using RFC 2047 rules, the behavior that you see would be a bug. -Hans From neuss at kit.edu Thu Oct 7 13:42:46 2010 From: neuss at kit.edu (Nicolas Neuss) Date: Thu, 07 Oct 2010 15:42:46 +0200 Subject: [hunchentoot-devel] Encoding problem In-Reply-To: ("Hans =?iso-8859-1?Q?H=FCbner=22's?= message of "Thu, 7 Oct 2010 14:23:07 +0200") References: <87vd5exmk5.fsf@ma-patru.mathematik.uni-karlsruhe.de> Message-ID: <878w2axgo9.fsf@ma-patru.mathematik.uni-karlsruhe.de> Hans H?bner writes: > Hi Nicolas, > > On Thu, Oct 7, 2010 at 13:35, Nicolas Neuss wrote: >> I am trying to make Shibboleth authentification work for an application >> of mine. ?For this I am using the Apache2 Shibboleth module (my server >> sits behind Apache). ?Everything works fine, but for one thing. ?The >> authentification data is passed in the headers section in UTF-8 format >> (probably). > > Before going into any depth on this, can you have a look at the > headers and find out in what character set they are encoded? HTTP > headers must be encoded as ISO-8859-1. If a client wants to send data > in different encoding, quoted-printable encoding as described in RFC > 2047 must be used. > > Thus, it would be a client error if you saw UTF-8 encoded data in > headers. If the data is properly encoded using RFC 2047 rules, the > behavior that you see would be a bug. > > -Hans Thanks Hans, I think this helps to pin down the problem. For information about headers: I have called the server information page while being Shibboleth authentificated and obtained the following: http://ruprecht.mathematik.uni-karlsruhe.de/misc/info.html I have the following in my Apache configuration file ... AuthType shibboleth ShibRequestSetting requireSession 1 require valid-user ProxyVia On ProxyPassInterpolateEnv On ProxyPass /sso http://127.0.0.1:8004 ProxyPassReverse /sso http://127.0.0.1:8004 RequestHeader set sn %{sn}e ... Maybe the data in the sn environment variable is in UTF-8 format and is not encoded correctly for the header? Nicolas From hans.huebner at gmail.com Thu Oct 7 13:48:41 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 7 Oct 2010 15:48:41 +0200 Subject: [hunchentoot-devel] Encoding problem In-Reply-To: <878w2axgo9.fsf@ma-patru.mathematik.uni-karlsruhe.de> References: <87vd5exmk5.fsf@ma-patru.mathematik.uni-karlsruhe.de> <878w2axgo9.fsf@ma-patru.mathematik.uni-karlsruhe.de> Message-ID: Hi Nicolas, I'm sorry, but I don't know anything about "Shibboleth authentification" and not enough about Apache configuration to be able to help you from here. On Thu, Oct 7, 2010 at 3:42 PM, Nicolas Neuss wrote: > ? ?RequestHeader set sn %{sn}e > ? ?... > ? ? > > Maybe the data in the sn environment variable is in UTF-8 format and is > not encoded correctly for the header? Maybe, and if this would be the case, it would be the source of the problem. -Hans From tomek.lipski at gmail.com Thu Oct 7 14:00:50 2010 From: tomek.lipski at gmail.com (Tomasz Lipski) Date: Thu, 7 Oct 2010 16:00:50 +0200 Subject: [hunchentoot-devel] Encoding problem In-Reply-To: <878w2axgo9.fsf@ma-patru.mathematik.uni-karlsruhe.de> References: <87vd5exmk5.fsf@ma-patru.mathematik.uni-karlsruhe.de> <878w2axgo9.fsf@ma-patru.mathematik.uni-karlsruhe.de> Message-ID: On 7 October 2010 15:42, Nicolas Neuss wrote: > http://ruprecht.mathematik.uni-karlsruhe.de/misc/info.html > Nicolas, I think that log from livehttpheaders Firefox plug-in/logging web proxy would be more useful. With that, you can check what is sent from the browser to the server directly in the HTTP layer. Best regards, Tomek Lipski From neuss at kit.edu Thu Oct 7 14:12:24 2010 From: neuss at kit.edu (Nicolas Neuss) Date: Thu, 07 Oct 2010 16:12:24 +0200 Subject: [hunchentoot-devel] Encoding problem In-Reply-To: (Tomasz Lipski's message of "Thu, 7 Oct 2010 16:00:50 +0200") References: <87vd5exmk5.fsf@ma-patru.mathematik.uni-karlsruhe.de> <878w2axgo9.fsf@ma-patru.mathematik.uni-karlsruhe.de> Message-ID: <874ocyxfav.fsf@ma-patru.mathematik.uni-karlsruhe.de> Tomasz Lipski writes: > On 7 October 2010 15:42, Nicolas Neuss wrote: >> http://ruprecht.mathematik.uni-karlsruhe.de/misc/info.html >> > > Nicolas, > > I think that log from livehttpheaders Firefox plug-in/logging web > proxy would be more useful. With that, you can check what is sent from > the browser to the server directly > in the HTTP layer. > > Best regards, > > Tomek Lipski IIUC, that doesn't help. The result is: Antwort-Header - https://ruprecht.mathematik.uni-karlsruhe.de/sso/test-shibboleth Date: Thu, 07 Oct 2010 14:09:45 GMT Server: Hunchentoot 1.1.0 Content-Length: 4687 Content-Type: text/html; charset=utf-8 Via: 1.1 ruprecht.mathematik.uni-karlsruhe.de Keep-Alive: timeout=15, max=100 Connection: Keep-Alive which shows that the encoding of the page shown in the browser should be correct. Thanks, Nicolas From hans.huebner at gmail.com Thu Oct 7 14:18:03 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 7 Oct 2010 16:18:03 +0200 Subject: [hunchentoot-devel] Encoding problem In-Reply-To: <874ocyxfav.fsf@ma-patru.mathematik.uni-karlsruhe.de> References: <87vd5exmk5.fsf@ma-patru.mathematik.uni-karlsruhe.de> <878w2axgo9.fsf@ma-patru.mathematik.uni-karlsruhe.de> <874ocyxfav.fsf@ma-patru.mathematik.uni-karlsruhe.de> Message-ID: Nicolas, I'd use Wireshark or another packet sniffing tool to capture the request as it is exchanged between Apache and Hunchentoot. In that capture, it would be obvious what encoding would be used for the headers. Lacking that, you could also try setting HUNCHENTOOT:*HEADER-STREAM* to *STANDARD-OUTPUT* or a stream of your liking and inspect its contents. Using an external sniffer would be safer in that you'd know that nothing has processed the headers, though. Given that you already speculated at the wrong encoding used in an environment variable that Apache uses, why don't you change that to use proper RFC2047 encoding? -Hans On Thu, Oct 7, 2010 at 4:12 PM, Nicolas Neuss wrote: > Tomasz Lipski writes: > >> On 7 October 2010 15:42, Nicolas Neuss wrote: >>> http://ruprecht.mathematik.uni-karlsruhe.de/misc/info.html >>> >> >> Nicolas, >> >> I think that log from livehttpheaders Firefox plug-in/logging web >> proxy would be more useful. With that, you can check what is sent from >> the browser to the server directly >> in the HTTP layer. >> >> Best regards, >> >> Tomek Lipski > > IIUC, that doesn't help. ?The result is: > > ? ?Antwort-Header - https://ruprecht.mathematik.uni-karlsruhe.de/sso/test-shibboleth > > ? ?Date: Thu, 07 Oct 2010 14:09:45 GMT > ? ?Server: Hunchentoot 1.1.0 > ? ?Content-Length: 4687 > ? ?Content-Type: text/html; charset=utf-8 > ? ?Via: 1.1 ruprecht.mathematik.uni-karlsruhe.de > ? ?Keep-Alive: timeout=15, max=100 > ? ?Connection: Keep-Alive > > which shows that the encoding of the page shown in the browser should be > correct. > > Thanks, Nicolas > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From neuss at kit.edu Thu Oct 7 14:33:42 2010 From: neuss at kit.edu (Nicolas Neuss) Date: Thu, 07 Oct 2010 16:33:42 +0200 Subject: [hunchentoot-devel] Encoding problem In-Reply-To: ("Hans =?iso-8859-1?Q?H=FCbner=22's?= message of "Thu, 7 Oct 2010 16:18:03 +0200") References: <87vd5exmk5.fsf@ma-patru.mathematik.uni-karlsruhe.de> <878w2axgo9.fsf@ma-patru.mathematik.uni-karlsruhe.de> <874ocyxfav.fsf@ma-patru.mathematik.uni-karlsruhe.de> Message-ID: <87zkuqvzqx.fsf@ma-patru.mathematik.uni-karlsruhe.de> Hans H?bner writes: > Nicolas, > > I'd use Wireshark or another packet sniffing tool to capture the > request as it is exchanged between Apache and Hunchentoot. In that > capture, it would be obvious what encoding would be used for the > headers. Lacking that, you could also try setting > HUNCHENTOOT:*HEADER-STREAM* to *STANDARD-OUTPUT* or a stream of your > liking and inspect its contents. Using an external sniffer would be > safer in that you'd know that nothing has processed the headers, > though. > > Given that you already speculated at the wrong encoding used in an > environment variable that Apache uses, why don't you change that to > use proper RFC2047 encoding? > > -Hans Hans, thanks for the hints. I'll try it, but it may take a while. As for why I don't teach Apache to properly encode, I simply don't know how:-) Googling didn't help. Nicolas P.S.: A simple preliminary solution might be to convert the string back myself using something like (flexi-streams:octets-to-string (flexi-streams:string-to-octets *x* :external-format :latin1) :external-format :utf-8) From fahree at gmail.com Tue Oct 12 20:56:47 2010 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Tue, 12 Oct 2010 16:56:47 -0400 Subject: [hunchentoot-devel] debug statement Message-ID: In the latest hunchentoot from svn, file request.lisp line 229, there is this statement which looks like a debug artefact that was committed by mistake, and that causes qres to fail its self-test: (format t "show-error ~A show-backtrace ~A error ~A backtrace: ~A~%" *show-lisp-errors-p* *show-lisp-backtraces-p* error backtrace) I suggest it be removed. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] It is no crime to be ignorant of economics, which is, after all, a specialized discipline and one that most people consider to be a "dismal science". But it *is* totally irresponsible to have a loud and vociferous opinion on economic subjects while remaining in this state of ignorance. ? Murray Rothbard From edi at agharta.de Tue Oct 12 21:41:14 2010 From: edi at agharta.de (Edi Weitz) Date: Tue, 12 Oct 2010 23:41:14 +0200 Subject: [hunchentoot-devel] debug statement In-Reply-To: References: Message-ID: Yup, good old FORMAT debugging... :) http://bknr.net/trac/changeset/4603/trunk/thirdparty/hunchentoot I've removed it. Thanks for catching it. Edi. On Tue, Oct 12, 2010 at 10:56 PM, Far? wrote: > In the latest hunchentoot from svn, file request.lisp line 229, there > is this statement which looks like a debug artefact that was committed > by mistake, and that causes qres to fail its self-test: > ? ? ? ? ? ? ?(format t "show-error ~A show-backtrace ~A error ~A > backtrace: ~A~%" > ? ? ? ? ? ? ? ? ? ? ?*show-lisp-errors-p* *show-lisp-backtraces-p* > error backtrace) > > I suggest it be removed. > > [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] > It is no crime to be ignorant of economics, which is, after all, a specialized > discipline and one that most people consider to be a "dismal science". > But it *is* totally irresponsible to have a loud and vociferous opinion > on economic subjects while remaining in this state of ignorance. > ? ? ? ?? Murray Rothbard > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > > From matt.lamari at gmail.com Sat Oct 16 10:49:01 2010 From: matt.lamari at gmail.com (Matt Lamari) Date: Sat, 16 Oct 2010 05:49:01 -0500 Subject: [hunchentoot-devel] How do I read the submit button value? Message-ID: <4CB9831D.2040403@gmail.com> Within a form, it's my understanding there can be more than one "submit" button, varying by their "value" attribute. Various pointers for this on the web explain how to determine which value was posted. How can I obtain this value via Hunchentoot? Thanks, Matt From hans.huebner at gmail.com Sat Oct 16 10:58:45 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sat, 16 Oct 2010 12:58:45 +0200 Subject: [hunchentoot-devel] How do I read the submit button value? In-Reply-To: <4CB9831D.2040403@gmail.com> References: <4CB9831D.2040403@gmail.com> Message-ID: Matt, you can use the GET-PARAMETERS*/POST-PARAMETERS* functions to get a list of all parameters (GET/POST respectively). Also, the easy handler architecture allows your handler to receive a list of all parameter values for parameters with the same name, please check out the documentation for DEFINE-EASY-HANDLER. -Hans On Sat, Oct 16, 2010 at 12:49 PM, Matt Lamari wrote: > > > Within a form, it's my understanding there can be more than one "submit" > button, varying by their "value" attribute. ?Various pointers for this > on the web explain how to determine which value was posted. > > How can I obtain this value via Hunchentoot? > > Thanks, > Matt > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From matt.lamari at gmail.com Sat Oct 16 16:05:37 2010 From: matt.lamari at gmail.com (Matt Lamari) Date: Sat, 16 Oct 2010 11:05:37 -0500 Subject: [hunchentoot-devel] How do I read the submit button value? In-Reply-To: References: <4CB9831D.2040403@gmail.com> Message-ID: <4CB9CD51.7080101@gmail.com> I tried to strip the example down, the HTML is below For post-parameters* and get-parameters* I get the following: Get Parameters: NIL Post Parameters: (("(Quantity)" . "")) Is there something wrong with the html that prevents the submit value from coming through too?
Quantity
From kiuma72 at gmail.com Sat Oct 16 16:13:25 2010 From: kiuma72 at gmail.com (Andrea Chiumenti) Date: Sat, 16 Oct 2010 18:13:25 +0200 Subject: [hunchentoot-devel] How do I read the submit button value? In-Reply-To: <4CB9CD51.7080101@gmail.com> References: <4CB9831D.2040403@gmail.com> <4CB9CD51.7080101@gmail.com> Message-ID: Matt, don't use intead. kiuma 2010/10/16 Matt Lamari : > > I tried to strip the example down, the HTML is below > > For post-parameters* and get-parameters* I get the ?following: > > Get Parameters: NIL > > Post Parameters: (("(Quantity)" . "")) > > Is there something wrong with the html that prevents the submit value > from coming through too? > > > >
> ? ? > ? ?
Quantity type='text' cols='40' value='' constraints='{}' required='true' />
> ? ?
> > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From hans.huebner at gmail.com Sat Oct 16 16:15:38 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sat, 16 Oct 2010 18:15:38 +0200 Subject: [hunchentoot-devel] How do I read the submit button value? In-Reply-To: <4CB9CD51.7080101@gmail.com> References: <4CB9831D.2040403@gmail.com> <4CB9CD51.7080101@gmail.com> Message-ID: Matt, your second input has no name. -Hans On Sat, Oct 16, 2010 at 6:05 PM, Matt Lamari wrote: > > I tried to strip the example down, the HTML is below > > For post-parameters* and get-parameters* I get the ?following: > > Get Parameters: NIL > > Post Parameters: (("(Quantity)" . "")) > > Is there something wrong with the html that prevents the submit value > from coming through too? > > > >
> ? ? > ? ?
Quantity type='text' cols='40' value='' constraints='{}' required='true' />
> ? ?
> > > From jackalmage at gmail.com Sat Oct 16 16:32:44 2010 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Sat, 16 Oct 2010 09:32:44 -0700 Subject: [hunchentoot-devel] How do I read the submit button value? In-Reply-To: References: <4CB9831D.2040403@gmail.com> <4CB9CD51.7080101@gmail.com> Message-ID: On Sat, Oct 16, 2010 at 9:13 AM, Andrea Chiumenti wrote: > Matt, > don't use > it's old java ?Struts 1.2 style, bleah.. and typical of old MVC action > based frameworks. > > use in terms of submission behavior. It's also usually identical in default appearance. There's not intended to be any difference between them. There is certainly no difference in terms of style or framework. The OP's problem is that an input needs a 'name' attribute to be included in the submitted data. A submit button without a 'name' attribute will still submit the form, but won't place its value in the data, so you can't tell which button was used to submit it. ~TJ From kiuma72 at gmail.com Sat Oct 16 16:43:46 2010 From: kiuma72 at gmail.com (Andrea Chiumenti) Date: Sat, 16 Oct 2010 18:43:46 +0200 Subject: [hunchentoot-devel] How do I read the submit button value? In-Reply-To: References: <4CB9831D.2040403@gmail.com> <4CB9CD51.7080101@gmail.com> Message-ID: before saying to someone that he says nonsense!!!! I'll give you this example, without comments. Make your conclusions! Think before
kiuma 2010/10/16 Tab Atkins Jr. : > On Sat, Oct 16, 2010 at 9:13 AM, Andrea Chiumenti wrote: >> Matt, >> don't use > >> it's old java ?Struts 1.2 style, bleah.. and typical of old MVC action >> based frameworks. >> >> use in terms of submission behavior. > It's also usually identical in default appearance. ?There's not > intended to be any difference between them. ?There is certainly no > difference in terms of style or framework. > > The OP's problem is that an input needs a 'name' attribute to be > included in the submitted data. ?A submit button without a 'name' > attribute will still submit the form, but won't place its value in the > data, so you can't tell which button was used to submit it. > > ~TJ > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From rm at tuxteam.de Sat Oct 16 18:42:18 2010 From: rm at tuxteam.de (rm at tuxteam.de) Date: Sat, 16 Oct 2010 20:42:18 +0200 Subject: [hunchentoot-devel] How do I read the submit button value?] Message-ID: <20101016184218.GC25343@seid-online.de> On Sat, Oct 16, 2010 at 06:43:46PM +0200, Andrea Chiumenti wrote: > before saying to someone that he says nonsense!!!! I would appreciate if we all could abstain from shouting at each other. Please no '!!!!'. > I'll give you this example, without comments. Make your conclusions! I guess Mr. Atkins was commenting on your staement that: " don't use References: <20101016184218.GC25343@seid-online.de> Message-ID: <4CBA077E.2070104@nist.gov> In English, saying something "makes no sense" is not quite as bad as saying it is "nonsense." "Makes no sense" is more like saying it is illogical. Though I suppose it could have been worded better. "This makes no sense to me..." is a much better. On 10/16/2010 02:42 PM, rm at tuxteam.de wrote: > On Sat, Oct 16, 2010 at 06:43:46PM +0200, Andrea Chiumenti wrote: >> before saying to someone that he says nonsense!!!! > I would appreciate if we all could abstain from shouting at each other. > Please no '!!!!'. > >> I'll give you this example, without comments. Make your conclusions! > I guess Mr. Atkins was commenting on your staement that: > > " don't use it's old java Struts 1.2 style, bleah.. and typical of old MVC > action based frameworks." > > calling this nonesense is actually rather euphemistic or polite. > IIRC input type submit was in the original html form spec. Long > before Struts ..... > And it has nothing whatsoever to do with the OP's problem. > > HTH Ralf Mattes > > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: peter_denno.vcf Type: text/x-vcard Size: 283 bytes Desc: not available URL: From blondbf at gmail.com Sun Oct 17 07:40:49 2010 From: blondbf at gmail.com (Blond BF) Date: Sun, 17 Oct 2010 11:40:49 +0400 Subject: [hunchentoot-devel] HTTP 500 error handling behavior customization Message-ID: So there was the need to handle the HTTP 500 error in two different ways depending on the current request string. So I threw error formatting code from START-OUTPUT and PROCESS-REQUEST to a separate function for start. Then I tried to make this function context-depended so I set the default value of *HTTP-ERROR-HANDLER* to this function and put error detection and handling code to HANDLE-REQUEST. Now HANDLE-REQUST responds to lisp and http errors by calling *HTTP-ERROR-HANDLER* and passing to it condition and backtrace in case of lisp error and dispatcher's return value in case of HTTP error. This error handler looks at RETURN-CODE* and formats corresponding error message. START-OUTPUT and PROCESS-REQUEST now just write what HANDLE-REQUEST returns. Now I can do something like (let ((*http-error-handler* 'custom-handler-for-this-site... in the dispatcher. There is little problem with compatibility: *HTTP-ERROR-HANDLER* takes error code as single argument before but now it taking error description string as single argument (can take return-code from reply object). I have no idea to save backward compatibility here. Here is a draft patch: diff --git a/acceptor.lisp b/acceptor.lisp index f90aa55..9f15947 100644 --- a/acceptor.lisp +++ b/acceptor.lisp @@ -421,6 +421,32 @@ chunked encoding, but acceptor is configured to not use it."))))) (mp:process-unstop (acceptor-process acceptor)) nil) +(defun handle-http-error (&optional description) + "Standard HTTP error handler. Looks at return code and +formats corresponding error message. Return value is error message +typically shown in user's web browser." + (let* ((return-code (return-code*)) + (reason-phrase (reason-phrase return-code))) + (format nil "~D ~A

~:*~A


~A

~A


~A

" + return-code reason-phrase + (case return-code + ((#.+http-moved-temporarily+ #.+http-moved-permanently+) + (format nil "The document has moved here" + (header-out :location))) + ((#.+http-authorization-required+) + "The server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials \(e.g., bad password), or your browser doesn't understand how to supply the credentials required.") + ((#.+http-forbidden+) + (format nil "You don't have permission to access ~A on this server." + (script-name *request*))) + ((#.+http-not-found+) + (format nil "The requested URL ~A was not found on this server." + (script-name *request*))) + ((#.+http-bad-request+) + "Your browser sent a request that this server could not understand.") + (otherwise "")) + (or description "") + (address-string)))) + (defun list-request-dispatcher (request) "The default request dispatcher which selects a request handler based on a list of individual request dispatchers all of which can @@ -433,8 +459,8 @@ either return a handler or neglect by returning NIL." (defmethod handle-request ((*acceptor* acceptor) (*request* request)) "Standard method for request handling. Calls the request dispatcher of *ACCEPTOR* to determine how the request should be handled. Also -sets up standard error handling which catches any errors within the -handler." +calls http error handler if return code is error code and sets up standard +error handling which catches any errors within the handler" (handler-bind ((error (lambda (cond) (when *log-lisp-errors-p* @@ -447,11 +473,30 @@ handler." ;; the stream (when *headers-sent* (setq *close-hunchentoot-stream* t)) + (setf (return-code*) +http-internal-server-error+) (throw 'handler-done - (values nil cond (and *show-lisp-backtraces-p* (get-backtrace)))))) + ;; A dispatcher can serve separate web-sites and + ;; set custom error pages for them by setting + ;; *http-error-handler* variable. + (funcall + *http-error-handler* + (let ((description + (format nil + "~A~%~A" + (if *show-lisp-errors-p* cond "") + (if *show-lisp-backtraces-p* (get-backtrace) "")))) + (regex-replace-all "\\n" (escape-for-html description) (format nil "
~%"))))))) (warning (lambda (cond) (when *log-lisp-warnings-p* (log-message *lisp-warnings-log-level* "~A" cond))))) - (with-debugger - (funcall (acceptor-request-dispatcher *acceptor*) *request*)))) + (let ((content (funcall (acceptor-request-dispatcher *acceptor*) *request*))) + ;; Call HTTP error handler when return code is not in approved + ;; list and http error handling is turned on. + ;; Pass dispatcher's output to error handler's input so + ;; dispatcher can format its own error description. + (if (or + (member (return-code*) *approved-return-codes*) + (null *handle-http-errors-p*)) + content + (funcall *http-error-handler* content))))) diff --git a/doc/index.xml b/doc/index.xml index df46c7c..a10a38f 100644 --- a/doc/index.xml +++ b/doc/index.xml @@ -1619,7 +1619,9 @@ The default method calls the acceptor's request dispatcher, but you can of course implement a different behaviour. The default method also sets up standard error handling for -the handler. +the handler and calls *HTTP-ERROR-HANDLER* +(with passing dispatcher's return value to it) if the request dispatcher +sets return code that not in *APPROVED-RETURN-CODES*

Might be a good place to bind or rebind special variables which can @@ -2698,18 +2700,16 @@ see *HANDLE-HTTP-ERRORS-P*. A generalized boolean that determines whether return codes which are not in *APPROVED-RETURN-CODES* are treated specially. When its value -is true (the default), either a default body for the return code or -the result of calling *HTTP-ERROR-HANDLER* is used. When the value is -NIL, no special action is taken and you are expected to supply your -own response body to describe the error. +is true (the default), the result of calling *HTTP-ERROR-HANDLER* is used to +format error message. When the value is NIL, no special action is taken and you are +expected to supply your own response body to describe the error. - Contains NIL (the default) or a function of one argument which is -called if the content handler has set a return code which is not in -*APPROVED-RETURN-CODES* -and *HANDLE-HTTP-ERRORS* is true. + Contains handle-http-error (the default) or a function of one +argument (error description) which is called if the content handler has set a return code which is not in +*APPROVED-RETURN-CODES* and *HANDLE-HTTP-ERRORS-P* is true. @@ -2777,6 +2777,19 @@ source code of REDIRECT for an example. + + optional description + string (formatted error message) + + Default HTTP error handler (see *HTTP-ERROR-HANDLER*). +

+ Looks at RETURN-CODE* and formats corresponding error message with + reason phrase (see REASON-PHRASE) and optional + description. +

+ + + path optional content-type nil diff --git a/headers.lisp b/headers.lisp index 89df868..0ae2320 100644 --- a/headers.lisp +++ b/headers.lisp @@ -74,9 +74,8 @@ writes them directly to the client as an HTTP header line.") (request *request*)) "Sends all headers and maybe the content body to *HUNCHENTOOT-STREAM*. Returns immediately and does nothing if called -more than once per request. Handles the supported return codes -accordingly. Called by PROCESS-REQUEST and/or SEND-HEADERS. Returns -the stream to write to." +more than once per request. Called by PROCESS-REQUEST and/or SEND-HEADERS. +Returns the stream to write to." ;; send headers only once (when *headers-sent* (return-from start-output)) @@ -135,41 +134,6 @@ the stream to write to." content-modified-p t return-code +http-internal-server-error+ reason-phrase (reason-phrase return-code))) - (unless (or (not *handle-http-errors-p*) - (member return-code *approved-return-codes*)) - ;; call error handler, if any - should return NIL if it can't - ;; handle the error - (let (error-handled-p) - (when *http-error-handler* - (setq error-handled-p (funcall *http-error-handler* return-code) - content (or error-handled-p content) - content-modified-p (or content-modified-p error-handled-p))) - ;; handle common return codes other than 200, which weren't - ;; handled by the error handler - (unless error-handled-p - (setf (content-type*) - "text/html; charset=iso-8859-1" - content-modified-p t - content - (format nil "~D ~A

~:*~A

~A


~A

" - return-code reason-phrase - (case return-code - ((#.+http-internal-server-error+) content) - ((#.+http-moved-temporarily+ #.+http-moved-permanently+) - (format nil "The document has moved here" - (escape-for-html (header-out :location)))) - ((#.+http-authorization-required+) - "The server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials \(e.g., bad password), or your browser doesn't understand how to supply the credentials required.") - ((#.+http-forbidden+) - (format nil "You don't have permission to access ~A on this server." - (escape-for-html (script-name request)))) - ((#.+http-not-found+) - (format nil "The requested URL ~A was not found on this server." - (escape-for-html (script-name request)))) - ((#.+http-bad-request+) - "Your browser sent a request that this server could not understand.") - (otherwise "")) - (address-string)))))) ;; start with status line (let ((first-line (format nil "HTTP/1.1 ~D ~A" return-code reason-phrase))) diff --git a/request.lisp b/request.lisp index ea0e2a7..1ef7daa 100644 --- a/request.lisp +++ b/request.lisp @@ -216,22 +216,7 @@ doing." (unwind-protect (with-mapped-conditions () (let* ((*request* request)) - (multiple-value-bind (body error backtrace) - ;; skip dispatch if bad request - (when (eql (return-code *reply*) +http-ok+) - (catch 'handler-done - (handle-request *acceptor* *request*))) - (when error - (setf (return-code *reply*) - +http-internal-server-error+)) - (start-output :content (cond ((and error *show-lisp-errors-p*) - (format nil "
~A~@[~%~%Backtrace:~A~]
" - (escape-for-html (format nil "~A" error)) - (when *show-lisp-backtraces-p* - (escape-for-html (format nil "~A" backtrace))))) - (error - "An error has occured.") - (t body)))))) + (start-output :content (catch 'handler-done (handle-request *acceptor* *request*))))) (dolist (path *tmp-files*) (when (and (pathnamep path) (probe-file path)) ;; the handler may have chosen to (re)move the uploaded diff --git a/specials.lisp b/specials.lisp index 7759ad5..84ccf66 100644 --- a/specials.lisp +++ b/specials.lisp @@ -270,10 +270,11 @@ DEFAULT-DISPATCHER.") "An alist of \(URI acceptor-names function) lists defined by DEFINE-EASY-HANDLER.") -(defvar *http-error-handler* nil - "Contains NIL \(the default) or a function of one argument which is -called if the content handler has set a return code which is not in -*APPROVED-RETURN-CODES* and *HANDLE-HTTP-ERRORS* is true.") +(defvar *http-error-handler* 'handle-http-error + "Contains 'handle-http-error (by default) or a function of one +argument (error description) which is called if the content handler +has set a return code which is not in *APPROVED-RETURN-CODES* and +*HANDLE-HTTP-ERRORS* is true") (defvar *handle-http-errors-p* t "A generalized boolean that determines whether return codes which From blondbf at gmail.com Sun Oct 17 07:53:05 2010 From: blondbf at gmail.com (Blond BF) Date: Sun, 17 Oct 2010 11:53:05 +0400 Subject: [hunchentoot-devel] HTTP 500 error handling behavior customization In-Reply-To: References: Message-ID: Seems to my mail web-interface broke text formatting, sorry. There is a patch as is in the attachment. On Sun, Oct 17, 2010 at 11:40 AM, Blond BF wrote: > So there was the need to handle the HTTP 500 error in two different > ways depending on the current request string. So I threw error > formatting code from START-OUTPUT and PROCESS-REQUEST to a separate > function for start. Then I tried to make this function > context-depended so I set the default value of *HTTP-ERROR-HANDLER* to > this function and put error detection and handling code to > HANDLE-REQUEST. > > Now HANDLE-REQUST responds to lisp and http errors by calling > *HTTP-ERROR-HANDLER* and passing to it condition and backtrace in case > of lisp error and dispatcher's return value in case of HTTP error. > This error handler looks at RETURN-CODE* and formats corresponding > error message. START-OUTPUT and PROCESS-REQUEST now just write what > HANDLE-REQUEST returns. > > Now I can do something like (let ((*http-error-handler* > 'custom-handler-for-this-site... in the dispatcher. > > There is little problem with compatibility: *HTTP-ERROR-HANDLER* takes > error code as single argument before but now it taking error > description string as single argument (can take return-code from reply > object). I have no idea to save backward compatibility here. > > Here is a draft patch: > ... -------------- next part -------------- A non-text attachment was scrubbed... Name: hunchentoot-patch Type: application/octet-stream Size: 13571 bytes Desc: not available URL: From kiuma72 at gmail.com Sun Oct 17 13:58:26 2010 From: kiuma72 at gmail.com (Andrea Chiumenti) Date: Sun, 17 Oct 2010 15:58:26 +0200 Subject: [hunchentoot-devel] How do I read the submit button value? In-Reply-To: References: <4CB9831D.2040403@gmail.com> <4CB9CD51.7080101@gmail.com> Message-ID: Matt, I'm trying to guess what you are doing. Hans has show you the functions you have to use and told you why you didn't get any value for the submit button, because you forgot the name attribute inside the input of type 'submit'. Having said that, I think, but maybe I'm wrong, that you are planning to have two submit buttons inside your page and then decide which action to call depending on the button the user hits. If you are going to use tag you may use value as submission parameter, but you can have the description you want for it (you may consider to decorate button label as well). Using button your action/parameter will not suffer of the i18n 'problem'. You'll also gain more eye-candy because you'll be able to do something like So input/submit and button/submit are only apparently identical. Cheers, kiuma 2010/10/16 Andrea Chiumenti : > before saying to someone that he says nonsense!!!! > > I'll give you this example, without comments. Make your conclusions! > > > ? > ? ?Think before > ? > ? > ? ?
> ? ? ? > ? ? ? > ? ?
> ? > > > kiuma > 2010/10/16 Tab Atkins Jr. : >> On Sat, Oct 16, 2010 at 9:13 AM, Andrea Chiumenti wrote: >>> Matt, >>> don't use >> >>> it's old java ?Struts 1.2 style, bleah.. and typical of old MVC action >>> based frameworks. >>> >>> use in terms of submission behavior. >> It's also usually identical in default appearance. ?There's not >> intended to be any difference between them. ?There is certainly no >> difference in terms of style or framework. >> >> The OP's problem is that an input needs a 'name' attribute to be >> included in the submitted data. ?A submit button without a 'name' >> attribute will still submit the form, but won't place its value in the >> data, so you can't tell which button was used to submit it. >> >> ~TJ >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > From jackalmage at gmail.com Mon Oct 18 16:29:41 2010 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Mon, 18 Oct 2010 09:29:41 -0700 Subject: [hunchentoot-devel] How do I read the submit button value? In-Reply-To: References: <4CB9831D.2040403@gmail.com> <4CB9CD51.7080101@gmail.com> Message-ID: On Sat, Oct 16, 2010 at 9:43 AM, Andrea Chiumenti wrote: > 2010/10/16 Tab Atkins Jr. : >> On Sat, Oct 16, 2010 at 9:13 AM, Andrea Chiumenti wrote: >>> Matt, >>> don't use >> >>> it's old java ?Struts 1.2 style, bleah.. and typical of old MVC action >>> based frameworks. >>> >>> use in terms of submission behavior. >> It's also usually identical in default appearance. ?There's not >> intended to be any difference between them. ?There is certainly no >> difference in terms of style or framework. >> >> The OP's problem is that an input needs a 'name' attribute to be >> included in the submitted data. ?A submit button without a 'name' >> attribute will still submit the form, but won't place its value in the >> data, so you can't tell which button was used to submit it. > > before saying to someone that he says nonsense!!!! > > I'll give you this example, without comments. Make your conclusions! > > > ? > ? ?Think before > ? > ? > ? ?
> ? ? ? > ? ? ? > ? ?
> ? > As Ralf said, I was commenting specifically on your statement that was somehow "old style" or related to java or certain frameworks. That is indeed nonsense; has absolutely nothing to do with frameworks or particular programming languages. Yes, with the label and the submit value are the same, while they can be different things with