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?
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?
>
>
>
>
>
>
>
> _______________________________________________
> 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?
>
>
>
>
>
>
>
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
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-typenil
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
Delete all
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 intead.
>>
>> This makes no sense. ? is identical to
>> foo 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 intead.
>>
>> This makes no sense. ? is identical to
>> foo 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 .
That has nothing to do with frameworks. It certainly has nothing to
do with the OP's problem, which was that his submit button didn't have
a 'name' attribute, and thus wasn't being submitted with the form.
~TJ
From dlw at itasoftware.com Wed Oct 27 16:08:07 2010
From: dlw at itasoftware.com (Daniel Weinreb)
Date: Wed, 27 Oct 2010 12:08:07 -0400
Subject: [hunchentoot-devel] Deploying CCL on a production server
In-Reply-To:
References:
Message-ID: <4CC84E67.5040701@itasoftware.com>
I used to work at BEA, on WebLogic Server, which our customers
used to implement advanced (by the standards of the time)
web sites. All of them used this strategy, namely have a
basic HTTP server which would serve up the static content,
and pass through the interesting stuff to the WebLogic
Server process.
On the other hand, patching Lisp dynamically is not the only
way to be able to do hot upgrade. Here at ITA, we do not
patch running Lisp processes; it's just too fraught with
intermediate states that are hard to have Q/A'ed in
advance. Fortunately for us, we never run just one
server; we always use a cluster of servers with a load
balancer. So we do a "rolling upgrade", where we
bring down each server and then bring up the new
version of the server, one machine at a time. Or,
we bring down half, upgrade those, and then switch
to the other half.
The issue you then must cope with is sessions with
many requests, some of which go to old-version servers
and some to new. (Even with code patching, there
are such windows.) The latter approach (halves)
means you only have to worry about a session
first seeing one of many old-version servers, followed
by one or many new version servers, which can
make things easier to reason about, but then
you jhave to make sure that only 1/2 of your
servers can handle the load. If you have
a mostly-diurnal load, you can do this "at night",
if your load goes down to < .5 or whatever.
The point is that the new version can be Q/A'ed
intensively before you do this and you don't
have to worry about things like "I updated
function X, but some existing thread has
an existing stack frame with the PC at the
old version of X" and such.
-- Dan
Shaneal Manek wrote:
> Generally, I deploy Hunchentoot behind a reverse proxy (just nginx for
> single-instance deployments, or HAProxy and nginx for more complex
> setups).
>
> In either case, I let nginx serve the static content (no need to waste
> the relatively expensive Lisp threads for serving images). In the
> single-hunchentoot case, nginx can serve a static error page when the
> hunchentoot instance is down. On the other hand, if you have a HAProxy
> in front of multiple hunchentoots, then as long as one hunchentoot is
> still up your site can continue with no downtime.
>
> -Shaneal
>
> On Fri, Sep 17, 2010 at 1:08 AM, Ron Garret wrote:
>
>> I'm getting close to deploying CCL on a production server, which has forced me to reluctantly reach the following conclusion: the fact that Lisp allows code to be changed dynamically means that unless you are extremely disciplined about how you patch the code in your server, it is not at all difficult to end up in a situation where the server needs to be restarted. When that happens, it would be nice not to have the server machine go completely dead, but instead to respond with a nice "Server temporarily unavailable" page, and maybe even continue to serve static content. So much as I'm a fan of Lisp and Hunchentoot, it seems to me that it's not a good idea to use that combination as the front-end of a production application, but instead to deploy the Lisp app as a FastCGI or the back-end of a proxy server setup.
>>
>
> _______________________________________________
> 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: