From lispercat at gmail.com  Thu Jan 20 19:08:56 2011
From: lispercat at gmail.com (AVS)
Date: Thu, 20 Jan 2011 14:08:56 -0500
Subject: [hunchentoot-devel] Hard to catch errors below process-request
Message-ID: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>

Hi

Recently I was trying to find out why the client received an empty response.
The problem was inside function start-output. Function call to
(string-to-octets content :external-format (reply-external-format*)
was throwing an exception (it was a non-latin character for latin
external-format) which I couldn't catch in debugger by setting
(setf hunchentoot:*handle-http-errors-p* nil)
(setf hunchentoot:*handle-http-errors-p* t)
(setf *catch-errors-p* nil)

Actually inside start-output I can write any crazy code that would
fail to compile or throw an exception, but for some reason this error
never gets shown at any level.
Maybe I am just missing something that I can specify, or maybe it only
happens on my end (I am using hunchentoot 1.1.1 on Ubuntu) please let
me know.

Thank you,
Andrei



From hans.huebner at gmail.com  Thu Jan 20 19:38:59 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 20 Jan 2011 20:38:59 +0100
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
Message-ID: <AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>

Andrei,

can you provide us with a simple test case that exposes the unwanted
behavior?  That'd make it easier for us to diagnose and maybe fix.

Thanks,
Hans

On Thu, Jan 20, 2011 at 8:08 PM, AVS <lispercat at gmail.com> wrote:
> Hi
>
> Recently I was trying to find out why the client received an empty response.
> The problem was inside function start-output. Function call to
> (string-to-octets content :external-format (reply-external-format*)
> was throwing an exception (it was a non-latin character for latin
> external-format) which I couldn't catch in debugger by setting
> (setf hunchentoot:*handle-http-errors-p* nil)
> (setf hunchentoot:*handle-http-errors-p* t)
> (setf *catch-errors-p* nil)
>
> Actually inside start-output I can write any crazy code that would
> fail to compile or throw an exception, but for some reason this error
> never gets shown at any level.
> Maybe I am just missing something that I can specify, or maybe it only
> happens on my end (I am using hunchentoot 1.1.1 on Ubuntu) please let
> me know.
>
> Thank you,
> Andrei
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From lispercat at gmail.com  Thu Jan 20 19:48:27 2011
From: lispercat at gmail.com (AVS)
Date: Thu, 20 Jan 2011 14:48:27 -0500
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
Message-ID: <AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>

The easiest I can think of is to put some garbage inside start-output
function (headers.lisp) and execute a request from any server running
on hunchentoot.
Let's say right after
    (when (stringp content)
      ;; if the content is a string, convert it to the proper external format
      (setf content (string-to-octets content :external-format
(reply-external-format*))))

put something like (/ 1 0) or (crazy-function a b).
I wonder if I can write a test case to isolate it more so you wouldn't
have to use your server code.

Thank you,
Andrei

On Thu, Jan 20, 2011 at 2:38 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
> Andrei,
>
> can you provide us with a simple test case that exposes the unwanted
> behavior? ?That'd make it easier for us to diagnose and maybe fix.
>
> Thanks,
> Hans
>
> On Thu, Jan 20, 2011 at 8:08 PM, AVS <lispercat at gmail.com> wrote:
>> Hi
>>
>> Recently I was trying to find out why the client received an empty response.
>> The problem was inside function start-output. Function call to
>> (string-to-octets content :external-format (reply-external-format*)
>> was throwing an exception (it was a non-latin character for latin
>> external-format) which I couldn't catch in debugger by setting
>> (setf hunchentoot:*handle-http-errors-p* nil)
>> (setf hunchentoot:*handle-http-errors-p* t)
>> (setf *catch-errors-p* nil)
>>
>> Actually inside start-output I can write any crazy code that would
>> fail to compile or throw an exception, but for some reason this error
>> never gets shown at any level.
>> Maybe I am just missing something that I can specify, or maybe it only
>> happens on my end (I am using hunchentoot 1.1.1 on Ubuntu) please let
>> me know.
>>
>> Thank you,
>> Andrei
>>
>> _______________________________________________
>> 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 hans.huebner at gmail.com  Thu Jan 20 21:04:38 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 20 Jan 2011 22:04:38 +0100
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
Message-ID: <AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>

On Thu, Jan 20, 2011 at 8:48 PM, AVS <lispercat at gmail.com> wrote:
> The easiest I can think of is to put some garbage inside start-output
> function (headers.lisp) and execute a request from any server running
> on hunchentoot.
> Let's say right after
> ? ?(when (stringp content)
> ? ? ?;; if the content is a string, convert it to the proper external format
> ? ? ?(setf content (string-to-octets content :external-format
> (reply-external-format*))))
>
> put something like (/ 1 0) or (crazy-function a b).
> I wonder if I can write a test case to isolate it more so you wouldn't
> have to use your server code.

I'm not sure if I understand you well, but are you changing
Hunchentoot itself and find it hard to debug, or are you writing an
application that uses Hunchentoot and find _that_ hard to debug.  If
the former, I think you'll have to come up with a proposed patch to
improve the behavior.  If the latter, I think I don't quite understand
what the issue is.

-Hans



From lispercat at gmail.com  Thu Jan 20 21:20:04 2011
From: lispercat at gmail.com (AVS)
Date: Thu, 20 Jan 2011 16:20:04 -0500
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
Message-ID: <AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>

The issue is this: If any of the functions fail when called from
start-output, you'll receive an empty response and the debugger will
not catch which function caused the error.
I described in the previous message that in my case (string-to-octets
..) failed. The failure may depend on your input.
I just said that to reproduce that scenario (silent error without
debugger being invoked) just put any failing function inside
start-output and issue a page request from the browser.
You'll receive an empty page and no debugger will be signaled.
Maybe it's a normal scenario, but it's hard to find the failing
function in this case.

Thank you,
Andrei


On Thu, Jan 20, 2011 at 4:04 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
> On Thu, Jan 20, 2011 at 8:48 PM, AVS <lispercat at gmail.com> wrote:
>> The easiest I can think of is to put some garbage inside start-output
>> function (headers.lisp) and execute a request from any server running
>> on hunchentoot.
>> Let's say right after
>> ? ?(when (stringp content)
>> ? ? ?;; if the content is a string, convert it to the proper external format
>> ? ? ?(setf content (string-to-octets content :external-format
>> (reply-external-format*))))
>>
>> put something like (/ 1 0) or (crazy-function a b).
>> I wonder if I can write a test case to isolate it more so you wouldn't
>> have to use your server code.
>
> I'm not sure if I understand you well, but are you changing
> Hunchentoot itself and find it hard to debug, or are you writing an
> application that uses Hunchentoot and find _that_ hard to debug. ?If
> the former, I think you'll have to come up with a proposed patch to
> improve the behavior. ?If the latter, I think I don't quite understand
> what the issue is.
>
> -Hans
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From hans.huebner at gmail.com  Thu Jan 20 21:27:24 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 20 Jan 2011 22:27:24 +0100
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
Message-ID: <AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>

On Thu, Jan 20, 2011 at 10:20 PM, AVS <lispercat at gmail.com> wrote:
> The issue is this: If any of the functions fail when called from
> start-output, you'll receive an empty response and the debugger will
> not catch which function caused the error.
> I described in the previous message that in my case (string-to-octets
> ..) failed. The failure may depend on your input.
> I just said that to reproduce that scenario (silent error without
> debugger being invoked) just put any failing function inside
> start-output and issue a page request from the browser.
> You'll receive an empty page and no debugger will be signaled.
> Maybe it's a normal scenario, but it's hard to find the failing
> function in this case.

I'm just trying to find out how pressing the problem is - Is it
something that a user or an application developer may run into, or is
it something that just happens when you poke around in the source code
and break it in unexpected ways?  From quickly glancing at
start-output, I see no calls back into user code, but you have run
into it nevertheless.  How, why?

-Hans



From lispercat at gmail.com  Thu Jan 20 21:45:39 2011
From: lispercat at gmail.com (AVS)
Date: Thu, 20 Jan 2011 16:45:39 -0500
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
	<AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
Message-ID: <AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>

Very simple. I get a string from server A. I expect the string to be
of latin characters. By (their) mistake there are a couple of unicode
characters in the string.
Now I want to use the string as part of my own server request handler
which I do via:
(defun handle-page-request ()
    (no-cache)
    *string-with-unicode*)

This request will produce an empty page. The developer says: "Why?! No
debugger was triggered, it went completely silent!".
The reason for that was when start-output called (string-to-octets
content :external-format (reply-external-format*)), the default
hunchentoot external-format is latin-1.
Since there are unicode characters in content variable,
string-to-octets will throw an exception which will not show anywhere.
Go figure it was a problem in your content string and that
string-to-octets blew up on it!
I understand that in most cases the developer writes some kind cl-who
code in the handler, or uses some content known to them.
But there are cases when you are dealing with 3-d party content which
you use to form your own.

To fix their problem I now create a handler like:
(defun handle-page-request ()
    (no-cache)
    (setf (hunchentoot:reply-external-format*)
(flex:make-external-format :utf-8 :eol-style :lf))
    (setf (hunchentoot:content-type*) "text/html; charset=utf-8")
    *string-with-unicode*)

Now, the problem I was talking about was that these types of errors
are hard to find.
If any exception thrown from within start-output triggered the
debugger I'd find the root cause of the problem in no time.

Thank you,
Andrei

On Thu, Jan 20, 2011 at 4:27 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
> On Thu, Jan 20, 2011 at 10:20 PM, AVS <lispercat at gmail.com> wrote:
>> The issue is this: If any of the functions fail when called from
>> start-output, you'll receive an empty response and the debugger will
>> not catch which function caused the error.
>> I described in the previous message that in my case (string-to-octets
>> ..) failed. The failure may depend on your input.
>> I just said that to reproduce that scenario (silent error without
>> debugger being invoked) just put any failing function inside
>> start-output and issue a page request from the browser.
>> You'll receive an empty page and no debugger will be signaled.
>> Maybe it's a normal scenario, but it's hard to find the failing
>> function in this case.
>
> I'm just trying to find out how pressing the problem is - Is it
> something that a user or an application developer may run into, or is
> it something that just happens when you poke around in the source code
> and break it in unexpected ways? ?From quickly glancing at
> start-output, I see no calls back into user code, but you have run
> into it nevertheless. ?How, why?
>
> -Hans
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From hans.huebner at gmail.com  Thu Jan 20 21:58:08 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 20 Jan 2011 22:58:08 +0100
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
	<AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
	<AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>
Message-ID: <AANLkTi=UasCWTOYbiHJ6EWScZtv15oEZyAHuKT9VKjM-@mail.gmail.com>

Andrei,

thank you for your error description.  I now understand what the
problem is and I agree that this is a bug that deserves fixing.  If
you don't have a proposal how it can be fixed, it would be immensely
helpful if you could provide me with a .lisp file that exposes the
problem (maybe using drakma to send a request that makes the handler
fail in the manner that you describe), as that would make it easier to
start working on the solution.

Thanks,
Hans

On Thu, Jan 20, 2011 at 10:45 PM, AVS <lispercat at gmail.com> wrote:
> Very simple. I get a string from server A. I expect the string to be
> of latin characters. By (their) mistake there are a couple of unicode
> characters in the string.
> Now I want to use the string as part of my own server request handler
> which I do via:
> (defun handle-page-request ()
> ? ?(no-cache)
> ? ?*string-with-unicode*)
>
> This request will produce an empty page. The developer says: "Why?! No
> debugger was triggered, it went completely silent!".
> The reason for that was when start-output called (string-to-octets
> content :external-format (reply-external-format*)), the default
> hunchentoot external-format is latin-1.
> Since there are unicode characters in content variable,
> string-to-octets will throw an exception which will not show anywhere.
> Go figure it was a problem in your content string and that
> string-to-octets blew up on it!
> I understand that in most cases the developer writes some kind cl-who
> code in the handler, or uses some content known to them.
> But there are cases when you are dealing with 3-d party content which
> you use to form your own.
>
> To fix their problem I now create a handler like:
> (defun handle-page-request ()
> ? ?(no-cache)
> ? ?(setf (hunchentoot:reply-external-format*)
> (flex:make-external-format :utf-8 :eol-style :lf))
> ? ?(setf (hunchentoot:content-type*) "text/html; charset=utf-8")
> ? ?*string-with-unicode*)
>
> Now, the problem I was talking about was that these types of errors
> are hard to find.
> If any exception thrown from within start-output triggered the
> debugger I'd find the root cause of the problem in no time.
>
> Thank you,
> Andrei
>
> On Thu, Jan 20, 2011 at 4:27 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
>> On Thu, Jan 20, 2011 at 10:20 PM, AVS <lispercat at gmail.com> wrote:
>>> The issue is this: If any of the functions fail when called from
>>> start-output, you'll receive an empty response and the debugger will
>>> not catch which function caused the error.
>>> I described in the previous message that in my case (string-to-octets
>>> ..) failed. The failure may depend on your input.
>>> I just said that to reproduce that scenario (silent error without
>>> debugger being invoked) just put any failing function inside
>>> start-output and issue a page request from the browser.
>>> You'll receive an empty page and no debugger will be signaled.
>>> Maybe it's a normal scenario, but it's hard to find the failing
>>> function in this case.
>>
>> I'm just trying to find out how pressing the problem is - Is it
>> something that a user or an application developer may run into, or is
>> it something that just happens when you poke around in the source code
>> and break it in unexpected ways? ?From quickly glancing at
>> start-output, I see no calls back into user code, but you have run
>> into it nevertheless. ?How, why?
>>
>> -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 lispercat at gmail.com  Thu Jan 20 22:20:59 2011
From: lispercat at gmail.com (AVS)
Date: Thu, 20 Jan 2011 17:20:59 -0500
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTi=UasCWTOYbiHJ6EWScZtv15oEZyAHuKT9VKjM-@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
	<AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
	<AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>
	<AANLkTi=UasCWTOYbiHJ6EWScZtv15oEZyAHuKT9VKjM-@mail.gmail.com>
Message-ID: <AANLkTinvhv5GUQ_rv=GCEBNLAW2KzEh-RiogWGU6QVN3@mail.gmail.com>

The simplest I can think of is:
(defun handle-page-request ()
  (let ((str (make-array 0 :element-type 'character :fill-pointer 0
:adjustable t)))
    (dolist (char '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t
#\RIGHT_DOUBLE_QUOTATION_MARK))
      (vector-push-extend char str))
    str))

Put this function in a dispatch table using something like
(hunchentoot:create-regex-dispatcher "test.html" 'handle-page-request)
When you type in "test.html" in the browser you'll see an empty page.

If you fix the function like this:
(defun handle-page-request ()
  (setf (hunchentoot:reply-external-format*)
(flex:make-external-format :utf-8 :eol-style :lf))
  (setf (hunchentoot:content-type*) "text/html; charset=utf-8")

  (let ((str (make-array 0 :element-type 'character :fill-pointer 0
:adjustable t)))
    (dolist (char '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t
#\RIGHT_DOUBLE_QUOTATION_MARK))
      (vector-push-extend char str))
    str))

You'll see ?test? in the browser.

Andrew


On Thu, Jan 20, 2011 at 4:58 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
> Andrei,
>
> thank you for your error description. ?I now understand what the
> problem is and I agree that this is a bug that deserves fixing. ?If
> you don't have a proposal how it can be fixed, it would be immensely
> helpful if you could provide me with a .lisp file that exposes the
> problem (maybe using drakma to send a request that makes the handler
> fail in the manner that you describe), as that would make it easier to
> start working on the solution.
>
> Thanks,
> Hans
>
> On Thu, Jan 20, 2011 at 10:45 PM, AVS <lispercat at gmail.com> wrote:
>> Very simple. I get a string from server A. I expect the string to be
>> of latin characters. By (their) mistake there are a couple of unicode
>> characters in the string.
>> Now I want to use the string as part of my own server request handler
>> which I do via:
>> (defun handle-page-request ()
>> ? ?(no-cache)
>> ? ?*string-with-unicode*)
>>
>> This request will produce an empty page. The developer says: "Why?! No
>> debugger was triggered, it went completely silent!".
>> The reason for that was when start-output called (string-to-octets
>> content :external-format (reply-external-format*)), the default
>> hunchentoot external-format is latin-1.
>> Since there are unicode characters in content variable,
>> string-to-octets will throw an exception which will not show anywhere.
>> Go figure it was a problem in your content string and that
>> string-to-octets blew up on it!
>> I understand that in most cases the developer writes some kind cl-who
>> code in the handler, or uses some content known to them.
>> But there are cases when you are dealing with 3-d party content which
>> you use to form your own.
>>
>> To fix their problem I now create a handler like:
>> (defun handle-page-request ()
>> ? ?(no-cache)
>> ? ?(setf (hunchentoot:reply-external-format*)
>> (flex:make-external-format :utf-8 :eol-style :lf))
>> ? ?(setf (hunchentoot:content-type*) "text/html; charset=utf-8")
>> ? ?*string-with-unicode*)
>>
>> Now, the problem I was talking about was that these types of errors
>> are hard to find.
>> If any exception thrown from within start-output triggered the
>> debugger I'd find the root cause of the problem in no time.
>>
>> Thank you,
>> Andrei
>>
>> On Thu, Jan 20, 2011 at 4:27 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
>>> On Thu, Jan 20, 2011 at 10:20 PM, AVS <lispercat at gmail.com> wrote:
>>>> The issue is this: If any of the functions fail when called from
>>>> start-output, you'll receive an empty response and the debugger will
>>>> not catch which function caused the error.
>>>> I described in the previous message that in my case (string-to-octets
>>>> ..) failed. The failure may depend on your input.
>>>> I just said that to reproduce that scenario (silent error without
>>>> debugger being invoked) just put any failing function inside
>>>> start-output and issue a page request from the browser.
>>>> You'll receive an empty page and no debugger will be signaled.
>>>> Maybe it's a normal scenario, but it's hard to find the failing
>>>> function in this case.
>>>
>>> I'm just trying to find out how pressing the problem is - Is it
>>> something that a user or an application developer may run into, or is
>>> it something that just happens when you poke around in the source code
>>> and break it in unexpected ways? ?From quickly glancing at
>>> start-output, I see no calls back into user code, but you have run
>>> into it nevertheless. ?How, why?
>>>
>>> -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
>



From hans.huebner at gmail.com  Thu Jan 20 22:44:27 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 20 Jan 2011 23:44:27 +0100
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTinvhv5GUQ_rv=GCEBNLAW2KzEh-RiogWGU6QVN3@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
	<AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
	<AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>
	<AANLkTi=UasCWTOYbiHJ6EWScZtv15oEZyAHuKT9VKjM-@mail.gmail.com>
	<AANLkTinvhv5GUQ_rv=GCEBNLAW2KzEh-RiogWGU6QVN3@mail.gmail.com>
Message-ID: <AANLkTin6zQwuamRTKMLDV=Wor7xgNprWKs3VKeYTyTUQ@mail.gmail.com>

Andrew,

I have been trying to reproduce the problem using CCL 1.6, but it does
not occur for me.  Can you please prepare a .lisp file that is
self-contained and that I can load to reproduce the problem that you
see?

Thanks,
Hans

On Thu, Jan 20, 2011 at 11:20 PM, AVS <lispercat at gmail.com> wrote:
> The simplest I can think of is:
> (defun handle-page-request ()
> ?(let ((str (make-array 0 :element-type 'character :fill-pointer 0
> :adjustable t)))
> ? ?(dolist (char '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t
> #\RIGHT_DOUBLE_QUOTATION_MARK))
> ? ? ?(vector-push-extend char str))
> ? ?str))
>
> Put this function in a dispatch table using something like
> (hunchentoot:create-regex-dispatcher "test.html" 'handle-page-request)
> When you type in "test.html" in the browser you'll see an empty page.
>
> If you fix the function like this:
> (defun handle-page-request ()
> ?(setf (hunchentoot:reply-external-format*)
> (flex:make-external-format :utf-8 :eol-style :lf))
> ?(setf (hunchentoot:content-type*) "text/html; charset=utf-8")
>
> ?(let ((str (make-array 0 :element-type 'character :fill-pointer 0
> :adjustable t)))
> ? ?(dolist (char '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t
> #\RIGHT_DOUBLE_QUOTATION_MARK))
> ? ? ?(vector-push-extend char str))
> ? ?str))
>
> You'll see ?test? in the browser.
>
> Andrew
>
>
> On Thu, Jan 20, 2011 at 4:58 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
>> Andrei,
>>
>> thank you for your error description. ?I now understand what the
>> problem is and I agree that this is a bug that deserves fixing. ?If
>> you don't have a proposal how it can be fixed, it would be immensely
>> helpful if you could provide me with a .lisp file that exposes the
>> problem (maybe using drakma to send a request that makes the handler
>> fail in the manner that you describe), as that would make it easier to
>> start working on the solution.
>>
>> Thanks,
>> Hans
>>
>> On Thu, Jan 20, 2011 at 10:45 PM, AVS <lispercat at gmail.com> wrote:
>>> Very simple. I get a string from server A. I expect the string to be
>>> of latin characters. By (their) mistake there are a couple of unicode
>>> characters in the string.
>>> Now I want to use the string as part of my own server request handler
>>> which I do via:
>>> (defun handle-page-request ()
>>> ? ?(no-cache)
>>> ? ?*string-with-unicode*)
>>>
>>> This request will produce an empty page. The developer says: "Why?! No
>>> debugger was triggered, it went completely silent!".
>>> The reason for that was when start-output called (string-to-octets
>>> content :external-format (reply-external-format*)), the default
>>> hunchentoot external-format is latin-1.
>>> Since there are unicode characters in content variable,
>>> string-to-octets will throw an exception which will not show anywhere.
>>> Go figure it was a problem in your content string and that
>>> string-to-octets blew up on it!
>>> I understand that in most cases the developer writes some kind cl-who
>>> code in the handler, or uses some content known to them.
>>> But there are cases when you are dealing with 3-d party content which
>>> you use to form your own.
>>>
>>> To fix their problem I now create a handler like:
>>> (defun handle-page-request ()
>>> ? ?(no-cache)
>>> ? ?(setf (hunchentoot:reply-external-format*)
>>> (flex:make-external-format :utf-8 :eol-style :lf))
>>> ? ?(setf (hunchentoot:content-type*) "text/html; charset=utf-8")
>>> ? ?*string-with-unicode*)
>>>
>>> Now, the problem I was talking about was that these types of errors
>>> are hard to find.
>>> If any exception thrown from within start-output triggered the
>>> debugger I'd find the root cause of the problem in no time.
>>>
>>> Thank you,
>>> Andrei
>>>
>>> On Thu, Jan 20, 2011 at 4:27 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
>>>> On Thu, Jan 20, 2011 at 10:20 PM, AVS <lispercat at gmail.com> wrote:
>>>>> The issue is this: If any of the functions fail when called from
>>>>> start-output, you'll receive an empty response and the debugger will
>>>>> not catch which function caused the error.
>>>>> I described in the previous message that in my case (string-to-octets
>>>>> ..) failed. The failure may depend on your input.
>>>>> I just said that to reproduce that scenario (silent error without
>>>>> debugger being invoked) just put any failing function inside
>>>>> start-output and issue a page request from the browser.
>>>>> You'll receive an empty page and no debugger will be signaled.
>>>>> Maybe it's a normal scenario, but it's hard to find the failing
>>>>> function in this case.
>>>>
>>>> I'm just trying to find out how pressing the problem is - Is it
>>>> something that a user or an application developer may run into, or is
>>>> it something that just happens when you poke around in the source code
>>>> and break it in unexpected ways? ?From quickly glancing at
>>>> start-output, I see no calls back into user code, but you have run
>>>> into it nevertheless. ?How, why?
>>>>
>>>> -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
>>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From lispercat at gmail.com  Thu Jan 20 22:57:00 2011
From: lispercat at gmail.com (AVS)
Date: Thu, 20 Jan 2011 17:57:00 -0500
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTin6zQwuamRTKMLDV=Wor7xgNprWKs3VKeYTyTUQ@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
	<AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
	<AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>
	<AANLkTi=UasCWTOYbiHJ6EWScZtv15oEZyAHuKT9VKjM-@mail.gmail.com>
	<AANLkTinvhv5GUQ_rv=GCEBNLAW2KzEh-RiogWGU6QVN3@mail.gmail.com>
	<AANLkTin6zQwuamRTKMLDV=Wor7xgNprWKs3VKeYTyTUQ@mail.gmail.com>
Message-ID: <AANLkTi=j+Cvdq76HpjdvfGfC0GE81=QfFdGYgxTFVvYh@mail.gmail.com>

I'll try to do this.
On you end do you see "test" or nothing?
Must by some sbcl 1.0.37 issue probably...

Andrew

On Thu, Jan 20, 2011 at 5:44 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
> Andrew,
>
> I have been trying to reproduce the problem using CCL 1.6, but it does
> not occur for me. ?Can you please prepare a .lisp file that is
> self-contained and that I can load to reproduce the problem that you
> see?
>
> Thanks,
> Hans
>
> On Thu, Jan 20, 2011 at 11:20 PM, AVS <lispercat at gmail.com> wrote:
>> The simplest I can think of is:
>> (defun handle-page-request ()
>> ?(let ((str (make-array 0 :element-type 'character :fill-pointer 0
>> :adjustable t)))
>> ? ?(dolist (char '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t
>> #\RIGHT_DOUBLE_QUOTATION_MARK))
>> ? ? ?(vector-push-extend char str))
>> ? ?str))
>>
>> Put this function in a dispatch table using something like
>> (hunchentoot:create-regex-dispatcher "test.html" 'handle-page-request)
>> When you type in "test.html" in the browser you'll see an empty page.
>>
>> If you fix the function like this:
>> (defun handle-page-request ()
>> ?(setf (hunchentoot:reply-external-format*)
>> (flex:make-external-format :utf-8 :eol-style :lf))
>> ?(setf (hunchentoot:content-type*) "text/html; charset=utf-8")
>>
>> ?(let ((str (make-array 0 :element-type 'character :fill-pointer 0
>> :adjustable t)))
>> ? ?(dolist (char '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t
>> #\RIGHT_DOUBLE_QUOTATION_MARK))
>> ? ? ?(vector-push-extend char str))
>> ? ?str))
>>
>> You'll see ?test? in the browser.
>>
>> Andrew
>>
>>
>> On Thu, Jan 20, 2011 at 4:58 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
>>> Andrei,
>>>
>>> thank you for your error description. ?I now understand what the
>>> problem is and I agree that this is a bug that deserves fixing. ?If
>>> you don't have a proposal how it can be fixed, it would be immensely
>>> helpful if you could provide me with a .lisp file that exposes the
>>> problem (maybe using drakma to send a request that makes the handler
>>> fail in the manner that you describe), as that would make it easier to
>>> start working on the solution.
>>>
>>> Thanks,
>>> Hans
>>>
>>> On Thu, Jan 20, 2011 at 10:45 PM, AVS <lispercat at gmail.com> wrote:
>>>> Very simple. I get a string from server A. I expect the string to be
>>>> of latin characters. By (their) mistake there are a couple of unicode
>>>> characters in the string.
>>>> Now I want to use the string as part of my own server request handler
>>>> which I do via:
>>>> (defun handle-page-request ()
>>>> ? ?(no-cache)
>>>> ? ?*string-with-unicode*)
>>>>
>>>> This request will produce an empty page. The developer says: "Why?! No
>>>> debugger was triggered, it went completely silent!".
>>>> The reason for that was when start-output called (string-to-octets
>>>> content :external-format (reply-external-format*)), the default
>>>> hunchentoot external-format is latin-1.
>>>> Since there are unicode characters in content variable,
>>>> string-to-octets will throw an exception which will not show anywhere.
>>>> Go figure it was a problem in your content string and that
>>>> string-to-octets blew up on it!
>>>> I understand that in most cases the developer writes some kind cl-who
>>>> code in the handler, or uses some content known to them.
>>>> But there are cases when you are dealing with 3-d party content which
>>>> you use to form your own.
>>>>
>>>> To fix their problem I now create a handler like:
>>>> (defun handle-page-request ()
>>>> ? ?(no-cache)
>>>> ? ?(setf (hunchentoot:reply-external-format*)
>>>> (flex:make-external-format :utf-8 :eol-style :lf))
>>>> ? ?(setf (hunchentoot:content-type*) "text/html; charset=utf-8")
>>>> ? ?*string-with-unicode*)
>>>>
>>>> Now, the problem I was talking about was that these types of errors
>>>> are hard to find.
>>>> If any exception thrown from within start-output triggered the
>>>> debugger I'd find the root cause of the problem in no time.
>>>>
>>>> Thank you,
>>>> Andrei
>>>>
>>>> On Thu, Jan 20, 2011 at 4:27 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
>>>>> On Thu, Jan 20, 2011 at 10:20 PM, AVS <lispercat at gmail.com> wrote:
>>>>>> The issue is this: If any of the functions fail when called from
>>>>>> start-output, you'll receive an empty response and the debugger will
>>>>>> not catch which function caused the error.
>>>>>> I described in the previous message that in my case (string-to-octets
>>>>>> ..) failed. The failure may depend on your input.
>>>>>> I just said that to reproduce that scenario (silent error without
>>>>>> debugger being invoked) just put any failing function inside
>>>>>> start-output and issue a page request from the browser.
>>>>>> You'll receive an empty page and no debugger will be signaled.
>>>>>> Maybe it's a normal scenario, but it's hard to find the failing
>>>>>> function in this case.
>>>>>
>>>>> I'm just trying to find out how pressing the problem is - Is it
>>>>> something that a user or an application developer may run into, or is
>>>>> it something that just happens when you poke around in the source code
>>>>> and break it in unexpected ways? ?From quickly glancing at
>>>>> start-output, I see no calls back into user code, but you have run
>>>>> into it nevertheless. ?How, why?
>>>>>
>>>>> -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
>>>
>>
>> _______________________________________________
>> 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 hans.huebner at gmail.com  Thu Jan 20 23:11:49 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 21 Jan 2011 00:11:49 +0100
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTi=j+Cvdq76HpjdvfGfC0GE81=QfFdGYgxTFVvYh@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
	<AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
	<AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>
	<AANLkTi=UasCWTOYbiHJ6EWScZtv15oEZyAHuKT9VKjM-@mail.gmail.com>
	<AANLkTinvhv5GUQ_rv=GCEBNLAW2KzEh-RiogWGU6QVN3@mail.gmail.com>
	<AANLkTin6zQwuamRTKMLDV=Wor7xgNprWKs3VKeYTyTUQ@mail.gmail.com>
	<AANLkTi=j+Cvdq76HpjdvfGfC0GE81=QfFdGYgxTFVvYh@mail.gmail.com>
Message-ID: <AANLkTint8j-ewtpnmrXM=_7VCsNq_4iAFZMNXLA=RN-f@mail.gmail.com>

On Thu, Jan 20, 2011 at 11:57 PM, AVS <lispercat at gmail.com> wrote:
> I'll try to do this.
> On you end do you see "test" or nothing?
> Must by some sbcl 1.0.37 issue probably...

I just see the "test" as expected.  I think that what you see is some
external format confusion.  This is not to say that there is no bug,
but I can't currently reproduce the problem.  I would like to have a
way to produce the problem with user code (i.e. without deliberately
breaking Hunchentoot internally).

Thanks,
Hans

P.S.: (coerce '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t
#\RIGHT_DOUBLE_QUOTATION_MARK) 'string)



From lispercat at gmail.com  Fri Jan 21 03:29:04 2011
From: lispercat at gmail.com (AVS)
Date: Thu, 20 Jan 2011 22:29:04 -0500
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTint8j-ewtpnmrXM=_7VCsNq_4iAFZMNXLA=RN-f@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
	<AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
	<AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>
	<AANLkTi=UasCWTOYbiHJ6EWScZtv15oEZyAHuKT9VKjM-@mail.gmail.com>
	<AANLkTinvhv5GUQ_rv=GCEBNLAW2KzEh-RiogWGU6QVN3@mail.gmail.com>
	<AANLkTin6zQwuamRTKMLDV=Wor7xgNprWKs3VKeYTyTUQ@mail.gmail.com>
	<AANLkTi=j+Cvdq76HpjdvfGfC0GE81=QfFdGYgxTFVvYh@mail.gmail.com>
	<AANLkTint8j-ewtpnmrXM=_7VCsNq_4iAFZMNXLA=RN-f@mail.gmail.com>
Message-ID: <AANLkTin9Syp7CA338_Yi4mMwV0ReMTNZNmWKC8qTUuBD@mail.gmail.com>

Thank you for the suggestion, Hans.
In the mean time could you try one thing? Put some bad code inside
start-output that will cause an exception (for instance (list a b)
without a, b defined, or (/ 1 0)). Also (setf *catch-errors-p* nil).
If things are as they should be it'll trigger the debugger. In my case
it doesn't which is the cause of the whole issue.
If it triggers the debugger break for you, it means there is something
related to sbcl I am using.

Thank you,
Andrei

On Thu, Jan 20, 2011 at 6:11 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
> On Thu, Jan 20, 2011 at 11:57 PM, AVS <lispercat at gmail.com> wrote:
>> I'll try to do this.
>> On you end do you see "test" or nothing?
>> Must by some sbcl 1.0.37 issue probably...
>
> I just see the "test" as expected. ?I think that what you see is some
> external format confusion. ?This is not to say that there is no bug,
> but I can't currently reproduce the problem. ?I would like to have a
> way to produce the problem with user code (i.e. without deliberately
> breaking Hunchentoot internally).
>
> Thanks,
> Hans
>
> P.S.: (coerce '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t
> #\RIGHT_DOUBLE_QUOTATION_MARK) 'string)
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From hans.huebner at gmail.com  Fri Jan 21 05:40:52 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 21 Jan 2011 06:40:52 +0100
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTin9Syp7CA338_Yi4mMwV0ReMTNZNmWKC8qTUuBD@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
	<AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
	<AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>
	<AANLkTi=UasCWTOYbiHJ6EWScZtv15oEZyAHuKT9VKjM-@mail.gmail.com>
	<AANLkTinvhv5GUQ_rv=GCEBNLAW2KzEh-RiogWGU6QVN3@mail.gmail.com>
	<AANLkTin6zQwuamRTKMLDV=Wor7xgNprWKs3VKeYTyTUQ@mail.gmail.com>
	<AANLkTi=j+Cvdq76HpjdvfGfC0GE81=QfFdGYgxTFVvYh@mail.gmail.com>
	<AANLkTint8j-ewtpnmrXM=_7VCsNq_4iAFZMNXLA=RN-f@mail.gmail.com>
	<AANLkTin9Syp7CA338_Yi4mMwV0ReMTNZNmWKC8qTUuBD@mail.gmail.com>
Message-ID: <AANLkTimnXBuaaWuAV1twDMeWU-U5Vch4gxiZEQnKbYN9@mail.gmail.com>

On Fri, Jan 21, 2011 at 4:29 AM, AVS <lispercat at gmail.com> wrote:
> Thank you for the suggestion, Hans.
> In the mean time could you try one thing? Put some bad code inside
> start-output that will cause an exception (for instance (list a b)
> without a, b defined, or (/ 1 0)). Also (setf *catch-errors-p* nil).
> If things are as they should be it'll trigger the debugger. In my case
> it doesn't which is the cause of the whole issue.
> If it triggers the debugger break for you, it means there is something
> related to sbcl I am using.

The debugger is not triggered, so the bug is real.  Having a way to
reproduce it by user code would be helpful nevertheless.

-Hans



From haragx at gmail.com  Fri Jan 21 09:48:51 2011
From: haragx at gmail.com (Phil Marneweck)
Date: Fri, 21 Jan 2011 11:48:51 +0200
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTimnXBuaaWuAV1twDMeWU-U5Vch4gxiZEQnKbYN9@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
	<AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
	<AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>
	<AANLkTi=UasCWTOYbiHJ6EWScZtv15oEZyAHuKT9VKjM-@mail.gmail.com>
	<AANLkTinvhv5GUQ_rv=GCEBNLAW2KzEh-RiogWGU6QVN3@mail.gmail.com>
	<AANLkTin6zQwuamRTKMLDV=Wor7xgNprWKs3VKeYTyTUQ@mail.gmail.com>
	<AANLkTi=j+Cvdq76HpjdvfGfC0GE81=QfFdGYgxTFVvYh@mail.gmail.com>
	<AANLkTint8j-ewtpnmrXM=_7VCsNq_4iAFZMNXLA=RN-f@mail.gmail.com>
	<AANLkTin9Syp7CA338_Yi4mMwV0ReMTNZNmWKC8qTUuBD@mail.gmail.com>
	<AANLkTimnXBuaaWuAV1twDMeWU-U5Vch4gxiZEQnKbYN9@mail.gmail.com>
Message-ID: <1295603331.1710.15.camel@devi>

On Fri, 2011-01-21 at 06:40 +0100, Hans H?bner wrote:

> On Fri, Jan 21, 2011 at 4:29 AM, AVS <lispercat at gmail.com> wrote:
> > Thank you for the suggestion, Hans.
> > In the mean time could you try one thing? Put some bad code inside
> > start-output that will cause an exception (for instance (list a b)
> > without a, b defined, or (/ 1 0)). Also (setf *catch-errors-p* nil).
> > If things are as they should be it'll trigger the debugger. In my case
> > it doesn't which is the cause of the whole issue.
> > If it triggers the debugger break for you, it means there is something
> > related to sbcl I am using.
> 
> The debugger is not triggered, so the bug is real.  Having a way to
> reproduce it by user code would be helpful nevertheless.
> 
> -Hans
> 


Like following?

(defpackage :test
  (:nicknames :test )
  (:use :cl :hunchentoot :cl-who) )


(in-package :test)

;;(hunchentoot:start (make-instance 'hunchentoot:acceptor :port 1111 ))


(hunchentoot::define-easy-handler  (eish :uri "/eish.html"
				 :default-request-type :both)
	 ()
	   (cl-who::with-html-output-to-string (*standard-output* nil :indent
t) 
	     (cl-who::str "Hello World  XXX")))


(defmacro with-debugging (&body body)
  ;; Using this as debugging tool because hunchentoot
  ;; swallows all errors here.
  `(handler-bind ((error #'invoke-debugger))
     , at body))

(defclass xxx ()
  ((ccc)) )


(defmethod handle-request :before ((*acceptor* hunchentoot::acceptor)
(*request* hunchentoot::request))
 
 ; (with-debugging   
   (slot-value (make-instance 'xxx) 'xxx) 
 ;)
)

Harag
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20110121/be4de58c/attachment.html>

From hans.huebner at gmail.com  Fri Jan 21 10:05:00 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 21 Jan 2011 11:05:00 +0100
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <1295603331.1710.15.camel@devi>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
	<AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
	<AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>
	<AANLkTi=UasCWTOYbiHJ6EWScZtv15oEZyAHuKT9VKjM-@mail.gmail.com>
	<AANLkTinvhv5GUQ_rv=GCEBNLAW2KzEh-RiogWGU6QVN3@mail.gmail.com>
	<AANLkTin6zQwuamRTKMLDV=Wor7xgNprWKs3VKeYTyTUQ@mail.gmail.com>
	<AANLkTi=j+Cvdq76HpjdvfGfC0GE81=QfFdGYgxTFVvYh@mail.gmail.com>
	<AANLkTint8j-ewtpnmrXM=_7VCsNq_4iAFZMNXLA=RN-f@mail.gmail.com>
	<AANLkTin9Syp7CA338_Yi4mMwV0ReMTNZNmWKC8qTUuBD@mail.gmail.com>
	<AANLkTimnXBuaaWuAV1twDMeWU-U5Vch4gxiZEQnKbYN9@mail.gmail.com>
	<1295603331.1710.15.camel@devi>
Message-ID: <AANLkTi=1PTLgLuh4Sx6=Ro=n76bX47ZfJNOm6BHa1VFZ@mail.gmail.com>

Harak, Andrei,

I had a look at the relevant positions in the Hunchentoot source and
would be interested in solving the problem so that errors are
reported, rather than swallowed, without requiring the user to set up
special handlers.  My time is limited, though, so if you could help me
by providing an executable test case that exposes the problem, it?d be
greatly appreciated.

Thanks,
Hans

On Fri, Jan 21, 2011 at 10:48 AM, Phil Marneweck <haragx at gmail.com> wrote:
> On Fri, 2011-01-21 at 06:40 +0100, Hans H?bner wrote:
>
> On Fri, Jan 21, 2011 at 4:29 AM, AVS <lispercat at gmail.com> wrote:
>> Thank you for the suggestion, Hans.
>> In the mean time could you try one thing? Put some bad code inside
>> start-output that will cause an exception (for instance (list a b)
>> without a, b defined, or (/ 1 0)). Also (setf *catch-errors-p* nil).
>> If things are as they should be it'll trigger the debugger. In my case
>> it doesn't which is the cause of the whole issue.
>> If it triggers the debugger break for you, it means there is something
>> related to sbcl I am using.
>
> The debugger is not triggered, so the bug is real.  Having a way to
> reproduce it by user code would be helpful nevertheless.
>
> -Hans
>
>
> Like following?
>
> (defpackage :test
> ? (:nicknames :test )
> ? (:use :cl :hunchentoot :cl-who) )
>
>
> (in-package :test)
>
> ;;(hunchentoot:start (make-instance 'hunchentoot:acceptor :port 1111 ))
>
>
> (hunchentoot::define-easy-handler? (eish :uri "/eish.html"
> :default-request-type :both)
> ()
> ?? (cl-who::with-html-output-to-string (*standard-output* nil :indent t)
> ???? (cl-who::str "Hello World? XXX")))
>
>
> (defmacro with-debugging (&body body)
> ? ;; Using this as debugging tool because hunchentoot
> ? ;; swallows all errors here.
> ? `(handler-bind ((error #'invoke-debugger))
> ???? , at body))
>
> (defclass xxx ()
> ? ((ccc)) )
>
>
> (defmethod handle-request :before ((*acceptor* hunchentoot::acceptor)
> (*request* hunchentoot::request))
>
> ; (with-debugging
> ?? (slot-value (make-instance 'xxx) 'xxx)
> ;)
> )
>
> Harag
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From lispercat at gmail.com  Fri Jan 21 16:15:40 2011
From: lispercat at gmail.com (AVS)
Date: Fri, 21 Jan 2011 11:15:40 -0500
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTi=1PTLgLuh4Sx6=Ro=n76bX47ZfJNOm6BHa1VFZ@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
	<AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
	<AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>
	<AANLkTi=UasCWTOYbiHJ6EWScZtv15oEZyAHuKT9VKjM-@mail.gmail.com>
	<AANLkTinvhv5GUQ_rv=GCEBNLAW2KzEh-RiogWGU6QVN3@mail.gmail.com>
	<AANLkTin6zQwuamRTKMLDV=Wor7xgNprWKs3VKeYTyTUQ@mail.gmail.com>
	<AANLkTi=j+Cvdq76HpjdvfGfC0GE81=QfFdGYgxTFVvYh@mail.gmail.com>
	<AANLkTint8j-ewtpnmrXM=_7VCsNq_4iAFZMNXLA=RN-f@mail.gmail.com>
	<AANLkTin9Syp7CA338_Yi4mMwV0ReMTNZNmWKC8qTUuBD@mail.gmail.com>
	<AANLkTimnXBuaaWuAV1twDMeWU-U5Vch4gxiZEQnKbYN9@mail.gmail.com>
	<1295603331.1710.15.camel@devi>
	<AANLkTi=1PTLgLuh4Sx6=Ro=n76bX47ZfJNOm6BHa1VFZ@mail.gmail.com>
Message-ID: <AANLkTinC0RF7Z3jG0BV7tXHx7tP91w1=3n_z9Cf2H=65@mail.gmail.com>

Here is the standalone file to reproduce the unicode failure problem
on my system (for the code below, put your path to quicklisp and save
the code in a test.lisp file ):
Load the file (for sbcl it's "sbcl --load test.lisp"), run lynx and
type in "lynx 127.0.0.1:1234/test.html". It should give you an empty
page.

;;test.lisp
(load "/your-path/quicklisp/setup.lisp")
(ql:quickload "hunchentoot")

(defpackage :test
  (:use :cl :hunchentoot))

(in-package :test)

(defparameter *server* (hunchentoot:start (make-instance
'hunchentoot:acceptor :port 1234)))
(hunchentoot:define-easy-handler (test :uri "/test.html") (name)
  (coerce '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t
#\RIGHT_DOUBLE_QUOTATION_MARK) 'string))
;;file end

Thank you,
Andrei


On Fri, Jan 21, 2011 at 5:05 AM, Hans H?bner <hans.huebner at gmail.com> wrote:
> Harak, Andrei,
>
> I had a look at the relevant positions in the Hunchentoot source and
> would be interested in solving the problem so that errors are
> reported, rather than swallowed, without requiring the user to set up
> special handlers. ?My time is limited, though, so if you could help me
> by providing an executable test case that exposes the problem, it?d be
> greatly appreciated.
>
> Thanks,
> Hans
>
> On Fri, Jan 21, 2011 at 10:48 AM, Phil Marneweck <haragx at gmail.com> wrote:
>> On Fri, 2011-01-21 at 06:40 +0100, Hans H?bner wrote:
>>
>> On Fri, Jan 21, 2011 at 4:29 AM, AVS <lispercat at gmail.com> wrote:
>>> Thank you for the suggestion, Hans.
>>> In the mean time could you try one thing? Put some bad code inside
>>> start-output that will cause an exception (for instance (list a b)
>>> without a, b defined, or (/ 1 0)). Also (setf *catch-errors-p* nil).
>>> If things are as they should be it'll trigger the debugger. In my case
>>> it doesn't which is the cause of the whole issue.
>>> If it triggers the debugger break for you, it means there is something
>>> related to sbcl I am using.
>>
>> The debugger is not triggered, so the bug is real. ?Having a way to
>> reproduce it by user code would be helpful nevertheless.
>>
>> -Hans
>>
>>
>> Like following?
>>
>> (defpackage :test
>> ? (:nicknames :test )
>> ? (:use :cl :hunchentoot :cl-who) )
>>
>>
>> (in-package :test)
>>
>> ;;(hunchentoot:start (make-instance 'hunchentoot:acceptor :port 1111 ))
>>
>>
>> (hunchentoot::define-easy-handler? (eish :uri "/eish.html"
>> :default-request-type :both)
>> ()
>> ?? (cl-who::with-html-output-to-string (*standard-output* nil :indent t)
>> ???? (cl-who::str "Hello World? XXX")))
>>
>>
>> (defmacro with-debugging (&body body)
>> ? ;; Using this as debugging tool because hunchentoot
>> ? ;; swallows all errors here.
>> ? `(handler-bind ((error #'invoke-debugger))
>> ???? , at body))
>>
>> (defclass xxx ()
>> ? ((ccc)) )
>>
>>
>> (defmethod handle-request :before ((*acceptor* hunchentoot::acceptor)
>> (*request* hunchentoot::request))
>>
>> ; (with-debugging
>> ?? (slot-value (make-instance 'xxx) 'xxx)
>> ;)
>> )
>>
>> Harag
>> _______________________________________________
>> 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 edi at weitz.de  Fri Jan 21 19:04:43 2011
From: edi at weitz.de (Edi Weitz)
Date: Fri, 21 Jan 2011 20:04:43 +0100
Subject: [hunchentoot-devel] Different accessors in define-easy-handler
In-Reply-To: <87mxo7gupl.fsf@ma-patru.mathematik.uni-karlsruhe.de>
References: <87mxo7gupl.fsf@ma-patru.mathematik.uni-karlsruhe.de>
Message-ID: <AANLkTi=-u6R_=YiQDFn4rcEzuTG3dRMo3+b62VA=y1pB@mail.gmail.com>

Thanks, this is finally in the repository now.  Sorry for the delay.

On Wed, Dec 15, 2010 at 12:07 PM, Nicolas Neuss <neuss at kit.edu> wrote:
> Hello,
>
> since some time I use a patch for DEFINE-EASY-HANDLER which makes it
> work correctly with multiple accessors (I hope). ?Here it is.
>
> (I am not quite sure if it has not been corrected yet. ?The patch is
> against Hunchentoot-1.1.1 from Quicklisp.)
>
> Thanks,
> Nicolas
>
>
> --- easy-handlers.lisp~ 2010-11-30 10:34:27.000000000 +0100
> +++ easy-handlers.lisp ?2010-11-30 10:46:39.000000000 +0100
> @@ -288,8 +288,11 @@
> ? ? ? ? ? ? ? `(progn
> ? ? ? ? ? ? ? ? ?(setq *easy-handler-alist*
> ? ? ? ? ? ? ? ? ? ? ? ?(delete-if (lambda (list)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(or (equal ,uri (first list))
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(eq ',name (third list))))
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(and (or (equal ,uri (first list))
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (eq ',name (third list)))
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (or (eq ,acceptor-names t)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (intersection ,acceptor-names
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (second list)))))
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? *easy-handler-alist*))
> ? ? ? ? ? ? ? ? ?(push (list ,uri ,acceptor-names ',name) *easy-handler-alist*)))))
> ? ? ? ?(defun ,name (&key ,@(loop for part in lambda-list
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>



From edi at weitz.de  Fri Jan 21 19:05:13 2011
From: edi at weitz.de (Edi Weitz)
Date: Fri, 21 Jan 2011 20:05:13 +0100
Subject: [hunchentoot-devel] Fix for ECL
In-Reply-To: <if2mtl$dim$1@dough.gmane.org>
References: <if2mtl$dim$1@dough.gmane.org>
Message-ID: <AANLkTinQvm5Jw3zncc=bSfzio2oDXp5z27tqoFLNfB68@mail.gmail.com>

And this is also in SVN now.  Thanks and again sorry for being so slow.

On Fri, Dec 24, 2010 at 6:57 PM, Sohail Somani <sohail at taggedtype.net> wrote:
> Hi there,
>
> In specials.lisp, ECL seems to require *supports-threads-p* to be set as
> follows:
>
> (eval-when (:compile-toplevel :load-toplevel :execute)
> ? (define-symbol-macro *supports-threads-p*
> ? ? #+:lispworks t
> ? ? #-:lispworks bt:*supports-threads-p*))
>
> Apparently the symbol macro is not available when compiling the file.
>
> Otherwise compiling the file twice works when loading.
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>



From edi at weitz.de  Fri Jan 21 19:08:22 2011
From: edi at weitz.de (Edi Weitz)
Date: Fri, 21 Jan 2011 20:08:22 +0100
Subject: [hunchentoot-devel] [Patch] Allow user to not send a
	Content-Type header
In-Reply-To: <4D1DD3CE.5000205@chaitanyagupta.com>
References: <4D1DD3CE.5000205@chaitanyagupta.com>
Message-ID: <AANLkTi=iH_76nt0mFmpHiY_AsN0TvrKJ1XtE1fGCO6tp@mail.gmail.com>

And this one too.  Thanks.

On Fri, Dec 31, 2010 at 1:59 PM, Chaitanya Gupta
<mail at chaitanyagupta.com> wrote:
> Hi,
>
> Right now, hunchentoot doesn't allow one to set a NULL Content-Type header
> -- so it is always sent to the client.
>
> With this patch, the user can
>
> ?(setf (content-type*) nil)
>
> And no Content-Type header will be sent in that case.
>
> Chaitanya
>
> --
> http://chaitanyagupta.com/blog/
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From edi at weitz.de  Fri Jan 21 19:18:19 2011
From: edi at weitz.de (Edi Weitz)
Date: Fri, 21 Jan 2011 20:18:19 +0100
Subject: [hunchentoot-devel] Exporting session-start & session-id
In-Reply-To: <877hiane5g.fsf@bitart.cc>
References: <87hbhgd3cm.fsf@tux.studbook.co.za>
	<AANLkTimbQY+o2oC4A1SGadB2_qNojsX-De2wV1t=PXK3@mail.gmail.com>
	<87eicja5pk.fsf@tux.studbook.co.za>
	<AANLkTi=6A5S13LQx3owJ426pq1JXh6ekXTn3G6MgojS_@mail.gmail.com>
	<877hiane5g.fsf@bitart.cc>
Message-ID: <AANLkTim+jmkpuuDSvX-n+xd6CErQN9aE7G4nq4uC0Z6w@mail.gmail.com>

Almost forgot this one.  Also in SVN now.

Thanks,
Edi.


On Sat, Sep 25, 2010 at 3:31 PM, Nico de Jager <ndj at bitart.cc> wrote:
> Hans H?bner <hans.huebner at gmail.com> writes:
>
>> On Fri, Sep 24, 2010 at 10:47, Nico de Jager <ndj at bitart.cc> wrote:
>>> Ok, thanks - no problem. I feel stupid asking this, but how do I get the
>>> svn version of Hunchentoot:
>>>
>>> $ svn co http://bknr.net/trac/browser/trunk/thirdparty/hunchentoot
>>> svn: XML data was not well-formed
>>
>> svn co http://bknr.net/svn/ediware
>>
>> will get you the whole ediware tree, which includes matching
>> development versions for Hunchentoot and its dependencies.
>>
>>> Also, do I have to update that ugly doc/index.xml file in a text editor,
>>> are there some kind of tool to edit it, or do you generate (parts of) it
>>> from the source code?
>>
>> It is an XML file, you can use any editor to edit it. ?It is the
>> master copy of the documentation. ?There are tools that we used to
>> extract the docstrings into the XML documentation, but they are not
>> readily deployable. ?I'd suggest that you add the docstrings and then
>> copy them to the XML file manually.
>>
>> Please make sure that it is still well formed after you've modified it
>> (xmllint can help with that). ?Emacs 23 includes the nXML mode, which
>> validates well-formedness on the fly.
>
> Attached, please find the patch. I added the new documentation at the
> end of the "Sessions" section, but will be disappointed if Edi don't
> make me rearrange it somehow :-)
>
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From hans.huebner at gmail.com  Fri Jan 21 21:34:11 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 21 Jan 2011 22:34:11 +0100
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTinC0RF7Z3jG0BV7tXHx7tP91w1=3n_z9Cf2H=65@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
	<AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
	<AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>
	<AANLkTi=UasCWTOYbiHJ6EWScZtv15oEZyAHuKT9VKjM-@mail.gmail.com>
	<AANLkTinvhv5GUQ_rv=GCEBNLAW2KzEh-RiogWGU6QVN3@mail.gmail.com>
	<AANLkTin6zQwuamRTKMLDV=Wor7xgNprWKs3VKeYTyTUQ@mail.gmail.com>
	<AANLkTi=j+Cvdq76HpjdvfGfC0GE81=QfFdGYgxTFVvYh@mail.gmail.com>
	<AANLkTint8j-ewtpnmrXM=_7VCsNq_4iAFZMNXLA=RN-f@mail.gmail.com>
	<AANLkTin9Syp7CA338_Yi4mMwV0ReMTNZNmWKC8qTUuBD@mail.gmail.com>
	<AANLkTimnXBuaaWuAV1twDMeWU-U5Vch4gxiZEQnKbYN9@mail.gmail.com>
	<1295603331.1710.15.camel@devi>
	<AANLkTi=1PTLgLuh4Sx6=Ro=n76bX47ZfJNOm6BHa1VFZ@mail.gmail.com>
	<AANLkTinC0RF7Z3jG0BV7tXHx7tP91w1=3n_z9Cf2H=65@mail.gmail.com>
Message-ID: <AANLkTi=Qs=rwXxajYERfVTcvfQ7Zf1zX19+xWN-SXW2k@mail.gmail.com>

Hi Andrei,

thank you for sending the reproduction script.  Fixing the problem in
a satisfactory fashion requires some refactoring that'll take me some
time and require review.  I'll keep you posted.

-Hans

On Fri, Jan 21, 2011 at 5:15 PM, AVS <lispercat at gmail.com> wrote:
> Here is the standalone file to reproduce the unicode failure problem
> on my system (for the code below, put your path to quicklisp and save
> the code in a test.lisp file ):
> Load the file (for sbcl it's "sbcl --load test.lisp"), run lynx and
> type in "lynx 127.0.0.1:1234/test.html". It should give you an empty
> page.
>
> ;;test.lisp
> (load "/your-path/quicklisp/setup.lisp")
> (ql:quickload "hunchentoot")
>
> (defpackage :test
> ?(:use :cl :hunchentoot))
>
> (in-package :test)
>
> (defparameter *server* (hunchentoot:start (make-instance
> 'hunchentoot:acceptor :port 1234)))
> (hunchentoot:define-easy-handler (test :uri "/test.html") (name)
> ?(coerce '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t
> #\RIGHT_DOUBLE_QUOTATION_MARK) 'string))
> ;;file end
>
> Thank you,
> Andrei
>
>
> On Fri, Jan 21, 2011 at 5:05 AM, Hans H?bner <hans.huebner at gmail.com> wrote:
>> Harak, Andrei,
>>
>> I had a look at the relevant positions in the Hunchentoot source and
>> would be interested in solving the problem so that errors are
>> reported, rather than swallowed, without requiring the user to set up
>> special handlers. ?My time is limited, though, so if you could help me
>> by providing an executable test case that exposes the problem, it?d be
>> greatly appreciated.
>>
>> Thanks,
>> Hans
>>
>> On Fri, Jan 21, 2011 at 10:48 AM, Phil Marneweck <haragx at gmail.com> wrote:
>>> On Fri, 2011-01-21 at 06:40 +0100, Hans H?bner wrote:
>>>
>>> On Fri, Jan 21, 2011 at 4:29 AM, AVS <lispercat at gmail.com> wrote:
>>>> Thank you for the suggestion, Hans.
>>>> In the mean time could you try one thing? Put some bad code inside
>>>> start-output that will cause an exception (for instance (list a b)
>>>> without a, b defined, or (/ 1 0)). Also (setf *catch-errors-p* nil).
>>>> If things are as they should be it'll trigger the debugger. In my case
>>>> it doesn't which is the cause of the whole issue.
>>>> If it triggers the debugger break for you, it means there is something
>>>> related to sbcl I am using.
>>>
>>> The debugger is not triggered, so the bug is real. ?Having a way to
>>> reproduce it by user code would be helpful nevertheless.
>>>
>>> -Hans
>>>
>>>
>>> Like following?
>>>
>>> (defpackage :test
>>> ? (:nicknames :test )
>>> ? (:use :cl :hunchentoot :cl-who) )
>>>
>>>
>>> (in-package :test)
>>>
>>> ;;(hunchentoot:start (make-instance 'hunchentoot:acceptor :port 1111 ))
>>>
>>>
>>> (hunchentoot::define-easy-handler? (eish :uri "/eish.html"
>>> :default-request-type :both)
>>> ()
>>> ?? (cl-who::with-html-output-to-string (*standard-output* nil :indent t)
>>> ???? (cl-who::str "Hello World? XXX")))
>>>
>>>
>>> (defmacro with-debugging (&body body)
>>> ? ;; Using this as debugging tool because hunchentoot
>>> ? ;; swallows all errors here.
>>> ? `(handler-bind ((error #'invoke-debugger))
>>> ???? , at body))
>>>
>>> (defclass xxx ()
>>> ? ((ccc)) )
>>>
>>>
>>> (defmethod handle-request :before ((*acceptor* hunchentoot::acceptor)
>>> (*request* hunchentoot::request))
>>>
>>> ; (with-debugging
>>> ?? (slot-value (make-instance 'xxx) 'xxx)
>>> ;)
>>> )
>>>
>>> Harag
>>> _______________________________________________
>>> 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
>



From hans.huebner at gmail.com  Fri Jan 21 22:34:25 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 21 Jan 2011 23:34:25 +0100
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTi=Qs=rwXxajYERfVTcvfQ7Zf1zX19+xWN-SXW2k@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
	<AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
	<AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>
	<AANLkTi=UasCWTOYbiHJ6EWScZtv15oEZyAHuKT9VKjM-@mail.gmail.com>
	<AANLkTinvhv5GUQ_rv=GCEBNLAW2KzEh-RiogWGU6QVN3@mail.gmail.com>
	<AANLkTin6zQwuamRTKMLDV=Wor7xgNprWKs3VKeYTyTUQ@mail.gmail.com>
	<AANLkTi=j+Cvdq76HpjdvfGfC0GE81=QfFdGYgxTFVvYh@mail.gmail.com>
	<AANLkTint8j-ewtpnmrXM=_7VCsNq_4iAFZMNXLA=RN-f@mail.gmail.com>
	<AANLkTin9Syp7CA338_Yi4mMwV0ReMTNZNmWKC8qTUuBD@mail.gmail.com>
	<AANLkTimnXBuaaWuAV1twDMeWU-U5Vch4gxiZEQnKbYN9@mail.gmail.com>
	<1295603331.1710.15.camel@devi>
	<AANLkTi=1PTLgLuh4Sx6=Ro=n76bX47ZfJNOm6BHa1VFZ@mail.gmail.com>
	<AANLkTinC0RF7Z3jG0BV7tXHx7tP91w1=3n_z9Cf2H=65@mail.gmail.com>
	<AANLkTi=Qs=rwXxajYERfVTcvfQ7Zf1zX19+xWN-SXW2k@mail.gmail.com>
Message-ID: <AANLkTimC5EN9xCDPqszM_L68OoWp_PMYZUGASwyqYx2E@mail.gmail.com>

I prepared a patch to improve Hunchentoot's error handling for errors
that occur in START-OUTPUT.  Please review
http://bknr.net/trac/changeset/4637/trunk, update from
svn+ssh://bknr.net/svn/ediware and try it out.

Thanks!
Hans

On Fri, Jan 21, 2011 at 10:34 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
> Hi Andrei,
>
> thank you for sending the reproduction script. ?Fixing the problem in
> a satisfactory fashion requires some refactoring that'll take me some
> time and require review. ?I'll keep you posted.
>
> -Hans
>
> On Fri, Jan 21, 2011 at 5:15 PM, AVS <lispercat at gmail.com> wrote:
>> Here is the standalone file to reproduce the unicode failure problem
>> on my system (for the code below, put your path to quicklisp and save
>> the code in a test.lisp file ):
>> Load the file (for sbcl it's "sbcl --load test.lisp"), run lynx and
>> type in "lynx 127.0.0.1:1234/test.html". It should give you an empty
>> page.
>>
>> ;;test.lisp
>> (load "/your-path/quicklisp/setup.lisp")
>> (ql:quickload "hunchentoot")
>>
>> (defpackage :test
>> ?(:use :cl :hunchentoot))
>>
>> (in-package :test)
>>
>> (defparameter *server* (hunchentoot:start (make-instance
>> 'hunchentoot:acceptor :port 1234)))
>> (hunchentoot:define-easy-handler (test :uri "/test.html") (name)
>> ?(coerce '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t
>> #\RIGHT_DOUBLE_QUOTATION_MARK) 'string))
>> ;;file end
>>
>> Thank you,
>> Andrei
>>
>>
>> On Fri, Jan 21, 2011 at 5:05 AM, Hans H?bner <hans.huebner at gmail.com> wrote:
>>> Harak, Andrei,
>>>
>>> I had a look at the relevant positions in the Hunchentoot source and
>>> would be interested in solving the problem so that errors are
>>> reported, rather than swallowed, without requiring the user to set up
>>> special handlers. ?My time is limited, though, so if you could help me
>>> by providing an executable test case that exposes the problem, it?d be
>>> greatly appreciated.
>>>
>>> Thanks,
>>> Hans
>>>
>>> On Fri, Jan 21, 2011 at 10:48 AM, Phil Marneweck <haragx at gmail.com> wrote:
>>>> On Fri, 2011-01-21 at 06:40 +0100, Hans H?bner wrote:
>>>>
>>>> On Fri, Jan 21, 2011 at 4:29 AM, AVS <lispercat at gmail.com> wrote:
>>>>> Thank you for the suggestion, Hans.
>>>>> In the mean time could you try one thing? Put some bad code inside
>>>>> start-output that will cause an exception (for instance (list a b)
>>>>> without a, b defined, or (/ 1 0)). Also (setf *catch-errors-p* nil).
>>>>> If things are as they should be it'll trigger the debugger. In my case
>>>>> it doesn't which is the cause of the whole issue.
>>>>> If it triggers the debugger break for you, it means there is something
>>>>> related to sbcl I am using.
>>>>
>>>> The debugger is not triggered, so the bug is real. ?Having a way to
>>>> reproduce it by user code would be helpful nevertheless.
>>>>
>>>> -Hans
>>>>
>>>>
>>>> Like following?
>>>>
>>>> (defpackage :test
>>>> ? (:nicknames :test )
>>>> ? (:use :cl :hunchentoot :cl-who) )
>>>>
>>>>
>>>> (in-package :test)
>>>>
>>>> ;;(hunchentoot:start (make-instance 'hunchentoot:acceptor :port 1111 ))
>>>>
>>>>
>>>> (hunchentoot::define-easy-handler? (eish :uri "/eish.html"
>>>> :default-request-type :both)
>>>> ()
>>>> ?? (cl-who::with-html-output-to-string (*standard-output* nil :indent t)
>>>> ???? (cl-who::str "Hello World? XXX")))
>>>>
>>>>
>>>> (defmacro with-debugging (&body body)
>>>> ? ;; Using this as debugging tool because hunchentoot
>>>> ? ;; swallows all errors here.
>>>> ? `(handler-bind ((error #'invoke-debugger))
>>>> ???? , at body))
>>>>
>>>> (defclass xxx ()
>>>> ? ((ccc)) )
>>>>
>>>>
>>>> (defmethod handle-request :before ((*acceptor* hunchentoot::acceptor)
>>>> (*request* hunchentoot::request))
>>>>
>>>> ; (with-debugging
>>>> ?? (slot-value (make-instance 'xxx) 'xxx)
>>>> ;)
>>>> )
>>>>
>>>> Harag
>>>> _______________________________________________
>>>> 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
>>
>



From lispercat at gmail.com  Fri Jan 21 23:45:35 2011
From: lispercat at gmail.com (AVS)
Date: Fri, 21 Jan 2011 18:45:35 -0500
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTimC5EN9xCDPqszM_L68OoWp_PMYZUGASwyqYx2E@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
	<AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
	<AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>
	<AANLkTi=UasCWTOYbiHJ6EWScZtv15oEZyAHuKT9VKjM-@mail.gmail.com>
	<AANLkTinvhv5GUQ_rv=GCEBNLAW2KzEh-RiogWGU6QVN3@mail.gmail.com>
	<AANLkTin6zQwuamRTKMLDV=Wor7xgNprWKs3VKeYTyTUQ@mail.gmail.com>
	<AANLkTi=j+Cvdq76HpjdvfGfC0GE81=QfFdGYgxTFVvYh@mail.gmail.com>
	<AANLkTint8j-ewtpnmrXM=_7VCsNq_4iAFZMNXLA=RN-f@mail.gmail.com>
	<AANLkTin9Syp7CA338_Yi4mMwV0ReMTNZNmWKC8qTUuBD@mail.gmail.com>
	<AANLkTimnXBuaaWuAV1twDMeWU-U5Vch4gxiZEQnKbYN9@mail.gmail.com>
	<1295603331.1710.15.camel@devi>
	<AANLkTi=1PTLgLuh4Sx6=Ro=n76bX47ZfJNOm6BHa1VFZ@mail.gmail.com>
	<AANLkTinC0RF7Z3jG0BV7tXHx7tP91w1=3n_z9Cf2H=65@mail.gmail.com>
	<AANLkTi=Qs=rwXxajYERfVTcvfQ7Zf1zX19+xWN-SXW2k@mail.gmail.com>
	<AANLkTimC5EN9xCDPqszM_L68OoWp_PMYZUGASwyqYx2E@mail.gmail.com>
Message-ID: <AANLkTikGQSs1VHuPOC838uAHx-BvEg3Sezees-2yrTEQ@mail.gmail.com>

Now it displays on the web page:
Internal Server Error
An error has occured
If  (setf hunchentoot:*handle-http-errors-p* nil) it just says "An
error has occured". Still doesn't trigger the debugger when (setf
*catch-errors-p* nil).
Also now the error is logged if *message-log-pathname* is specified.
Great progress! Can we still have the debugger triggered?

Thank you,
Andrew

On Fri, Jan 21, 2011 at 5:34 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
> I prepared a patch to improve Hunchentoot's error handling for errors
> that occur in START-OUTPUT. ?Please review
> http://bknr.net/trac/changeset/4637/trunk, update from
> svn+ssh://bknr.net/svn/ediware and try it out.
>
> Thanks!
> Hans
>
> On Fri, Jan 21, 2011 at 10:34 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
>> Hi Andrei,
>>
>> thank you for sending the reproduction script. ?Fixing the problem in
>> a satisfactory fashion requires some refactoring that'll take me some
>> time and require review. ?I'll keep you posted.
>>
>> -Hans
>>
>> On Fri, Jan 21, 2011 at 5:15 PM, AVS <lispercat at gmail.com> wrote:
>>> Here is the standalone file to reproduce the unicode failure problem
>>> on my system (for the code below, put your path to quicklisp and save
>>> the code in a test.lisp file ):
>>> Load the file (for sbcl it's "sbcl --load test.lisp"), run lynx and
>>> type in "lynx 127.0.0.1:1234/test.html". It should give you an empty
>>> page.
>>>
>>> ;;test.lisp
>>> (load "/your-path/quicklisp/setup.lisp")
>>> (ql:quickload "hunchentoot")
>>>
>>> (defpackage :test
>>> ?(:use :cl :hunchentoot))
>>>
>>> (in-package :test)
>>>
>>> (defparameter *server* (hunchentoot:start (make-instance
>>> 'hunchentoot:acceptor :port 1234)))
>>> (hunchentoot:define-easy-handler (test :uri "/test.html") (name)
>>> ?(coerce '(#\RIGHT_DOUBLE_QUOTATION_MARK #\t #\e #\s #\t
>>> #\RIGHT_DOUBLE_QUOTATION_MARK) 'string))
>>> ;;file end
>>>
>>> Thank you,
>>> Andrei
>>>
>>>
>>> On Fri, Jan 21, 2011 at 5:05 AM, Hans H?bner <hans.huebner at gmail.com> wrote:
>>>> Harak, Andrei,
>>>>
>>>> I had a look at the relevant positions in the Hunchentoot source and
>>>> would be interested in solving the problem so that errors are
>>>> reported, rather than swallowed, without requiring the user to set up
>>>> special handlers. ?My time is limited, though, so if you could help me
>>>> by providing an executable test case that exposes the problem, it?d be
>>>> greatly appreciated.
>>>>
>>>> Thanks,
>>>> Hans
>>>>
>>>> On Fri, Jan 21, 2011 at 10:48 AM, Phil Marneweck <haragx at gmail.com> wrote:
>>>>> On Fri, 2011-01-21 at 06:40 +0100, Hans H?bner wrote:
>>>>>
>>>>> On Fri, Jan 21, 2011 at 4:29 AM, AVS <lispercat at gmail.com> wrote:
>>>>>> Thank you for the suggestion, Hans.
>>>>>> In the mean time could you try one thing? Put some bad code inside
>>>>>> start-output that will cause an exception (for instance (list a b)
>>>>>> without a, b defined, or (/ 1 0)). Also (setf *catch-errors-p* nil).
>>>>>> If things are as they should be it'll trigger the debugger. In my case
>>>>>> it doesn't which is the cause of the whole issue.
>>>>>> If it triggers the debugger break for you, it means there is something
>>>>>> related to sbcl I am using.
>>>>>
>>>>> The debugger is not triggered, so the bug is real. ?Having a way to
>>>>> reproduce it by user code would be helpful nevertheless.
>>>>>
>>>>> -Hans
>>>>>
>>>>>
>>>>> Like following?
>>>>>
>>>>> (defpackage :test
>>>>> ? (:nicknames :test )
>>>>> ? (:use :cl :hunchentoot :cl-who) )
>>>>>
>>>>>
>>>>> (in-package :test)
>>>>>
>>>>> ;;(hunchentoot:start (make-instance 'hunchentoot:acceptor :port 1111 ))
>>>>>
>>>>>
>>>>> (hunchentoot::define-easy-handler? (eish :uri "/eish.html"
>>>>> :default-request-type :both)
>>>>> ()
>>>>> ?? (cl-who::with-html-output-to-string (*standard-output* nil :indent t)
>>>>> ???? (cl-who::str "Hello World? XXX")))
>>>>>
>>>>>
>>>>> (defmacro with-debugging (&body body)
>>>>> ? ;; Using this as debugging tool because hunchentoot
>>>>> ? ;; swallows all errors here.
>>>>> ? `(handler-bind ((error #'invoke-debugger))
>>>>> ???? , at body))
>>>>>
>>>>> (defclass xxx ()
>>>>> ? ((ccc)) )
>>>>>
>>>>>
>>>>> (defmethod handle-request :before ((*acceptor* hunchentoot::acceptor)
>>>>> (*request* hunchentoot::request))
>>>>>
>>>>> ; (with-debugging
>>>>> ?? (slot-value (make-instance 'xxx) 'xxx)
>>>>> ;)
>>>>> )
>>>>>
>>>>> Harag
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>
> _______________________________________________
> 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 Jan 22 06:54:48 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sat, 22 Jan 2011 07:54:48 +0100
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTikGQSs1VHuPOC838uAHx-BvEg3Sezees-2yrTEQ@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
	<AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
	<AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>
	<AANLkTi=UasCWTOYbiHJ6EWScZtv15oEZyAHuKT9VKjM-@mail.gmail.com>
	<AANLkTinvhv5GUQ_rv=GCEBNLAW2KzEh-RiogWGU6QVN3@mail.gmail.com>
	<AANLkTin6zQwuamRTKMLDV=Wor7xgNprWKs3VKeYTyTUQ@mail.gmail.com>
	<AANLkTi=j+Cvdq76HpjdvfGfC0GE81=QfFdGYgxTFVvYh@mail.gmail.com>
	<AANLkTint8j-ewtpnmrXM=_7VCsNq_4iAFZMNXLA=RN-f@mail.gmail.com>
	<AANLkTin9Syp7CA338_Yi4mMwV0ReMTNZNmWKC8qTUuBD@mail.gmail.com>
	<AANLkTimnXBuaaWuAV1twDMeWU-U5Vch4gxiZEQnKbYN9@mail.gmail.com>
	<1295603331.1710.15.camel@devi>
	<AANLkTi=1PTLgLuh4Sx6=Ro=n76bX47ZfJNOm6BHa1VFZ@mail.gmail.com>
	<AANLkTinC0RF7Z3jG0BV7tXHx7tP91w1=3n_z9Cf2H=65@mail.gmail.com>
	<AANLkTi=Qs=rwXxajYERfVTcvfQ7Zf1zX19+xWN-SXW2k@mail.gmail.com>
	<AANLkTimC5EN9xCDPqszM_L68OoWp_PMYZUGASwyqYx2E@mail.gmail.com>
	<AANLkTikGQSs1VHuPOC838uAHx-BvEg3Sezees-2yrTEQ@mail.gmail.com>
Message-ID: <AANLkTikGYV5kb6gU7NZf7NxHi9446o1k_Rtcvf1Qwc4_@mail.gmail.com>

On Sat, Jan 22, 2011 at 12:45 AM, AVS <lispercat at gmail.com> wrote:
> Now it displays on the web page:
> Internal Server Error
> An error has occured

This is the right thing.  You can set *SHOW-LISP-ERRORS-P* to display
the error to the client, and *LOG-LISP-ERRORS-P* to log them to the
log file.

> If ?(setf hunchentoot:*handle-http-errors-p* nil) it just says "An
> error has occured".

*HANDLE-HTTP-ERRORS-P* is not relevant here, I think.  At least I did
not intend to modify its behavior.

> Still doesn't trigger the debugger when (setf
> *catch-errors-p* nil).

http://bknr.net/trac/changeset/4638/trunk fixes this.  Please update
and try again.

-Hans



From hans.huebner at gmail.com  Sun Jan 23 09:49:16 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sun, 23 Jan 2011 10:49:16 +0100
Subject: [hunchentoot-devel] Logging API and default behavior changed
Message-ID: <AANLkTi=3S4b-keu0bFiNg2C2NhpL_JyVrX9sL_GXePfd@mail.gmail.com>

Hi,

I have made an incompatible change to Hunchentoot's logging API
(http://bknr.net/trac/changeset/4639).

To sum up:  The old special variables to configure the log paths as
well as the -logger slots in the acceptors are gone.  Instead,
Hunchentoot now has per-acceptor slots containing the log pathnames,
if any.  Logging is performed by calling the ACCEPTOR-LOG-ACCESS and
ACCEPTOR-LOG-MESSAGE generic functions that can be specialized for
derived logger classes.

Previously, it was possible to disable logging altogether by setting
the log pathnames to NIL, which also was the default.  I have changed
that so that if a log pathname is NIL, the log entry is written to
CL:*ERROR-OUTPUT* instead.  This seems to be a more helpful behavior.
If an application desires to switch off logging completely, it now
needs to either set the log pathnames to "/dev/null" (wasteful, but
quick) or implement methods for the logging functions above.

Please let me know if there are any problems with this change, apart
from the incompatibility.

-Hans



From asf at boinkor.net  Mon Jan 24 01:21:50 2011
From: asf at boinkor.net (Andreas Fuchs)
Date: Sun, 23 Jan 2011 17:21:50 -0800
Subject: [hunchentoot-devel] Logging API and default behavior changed
In-Reply-To: <AANLkTi=3S4b-keu0bFiNg2C2NhpL_JyVrX9sL_GXePfd@mail.gmail.com>
References: <AANLkTi=3S4b-keu0bFiNg2C2NhpL_JyVrX9sL_GXePfd@mail.gmail.com>
Message-ID: <AANLkTikQore-zEey=R3HYn8S=k7F0ZVXSr-7titKn5be@mail.gmail.com>

On Sun, Jan 23, 2011 at 01:49, Hans H?bner <hans.huebner at gmail.com> wrote:
> Previously, it was possible to disable logging altogether by setting
> the log pathnames to NIL, which also was the default. ?I have changed
> that so that if a log pathname is NIL, the log entry is written to
> CL:*ERROR-OUTPUT* instead. ?This seems to be a more helpful behavior.
> If an application desires to switch off logging completely, it now
> needs to either set the log pathnames to "/dev/null" (wasteful, but
> quick) or implement methods for the logging functions above.

I think that binding CL:*ERROR-OUTPUT* to an empty broadcast stream
should also work for disabling logging. But that will still have the
performance cost of writing to a stream; overriding the methods seems
like the better choice for deploying code somewhere.

Cheers,
-- 
Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs



From lispercat at gmail.com  Mon Jan 24 15:50:38 2011
From: lispercat at gmail.com (AVS)
Date: Mon, 24 Jan 2011 10:50:38 -0500
Subject: [hunchentoot-devel] Hard to catch errors below process-request
In-Reply-To: <AANLkTikGYV5kb6gU7NZf7NxHi9446o1k_Rtcvf1Qwc4_@mail.gmail.com>
References: <AANLkTinQhQ8EUfibYLaMXRAMMggcJKyngbjR8aQEA6dU@mail.gmail.com>
	<AANLkTikWD6UDojMNiDhRv0=iNdaP+dyG8i1U6erwNokx@mail.gmail.com>
	<AANLkTin7ej2n73V6UB+TQTucp1b0iqCjhYE8rKjOnpZi@mail.gmail.com>
	<AANLkTim50iuLmMv9gLJUdPn+4v9M=M5H1dSgA6NAhyLV@mail.gmail.com>
	<AANLkTi=skTSdMXdso5kSWX_LgX4_za46wWKzaKumHam4@mail.gmail.com>
	<AANLkTikeNfERaxczq1t_DAy65TaZUGsJMznRfeX6peNP@mail.gmail.com>
	<AANLkTi=M_-RgNZeGAdEUKQZOBoWaAyHeoEUrqMyUHFMg@mail.gmail.com>
	<AANLkTi=UasCWTOYbiHJ6EWScZtv15oEZyAHuKT9VKjM-@mail.gmail.com>
	<AANLkTinvhv5GUQ_rv=GCEBNLAW2KzEh-RiogWGU6QVN3@mail.gmail.com>
	<AANLkTin6zQwuamRTKMLDV=Wor7xgNprWKs3VKeYTyTUQ@mail.gmail.com>
	<AANLkTi=j+Cvdq76HpjdvfGfC0GE81=QfFdGYgxTFVvYh@mail.gmail.com>
	<AANLkTint8j-ewtpnmrXM=_7VCsNq_4iAFZMNXLA=RN-f@mail.gmail.com>
	<AANLkTin9Syp7CA338_Yi4mMwV0ReMTNZNmWKC8qTUuBD@mail.gmail.com>
	<AANLkTimnXBuaaWuAV1twDMeWU-U5Vch4gxiZEQnKbYN9@mail.gmail.com>
	<1295603331.1710.15.camel@devi>
	<AANLkTi=1PTLgLuh4Sx6=Ro=n76bX47ZfJNOm6BHa1VFZ@mail.gmail.com>
	<AANLkTinC0RF7Z3jG0BV7tXHx7tP91w1=3n_z9Cf2H=65@mail.gmail.com>
	<AANLkTi=Qs=rwXxajYERfVTcvfQ7Zf1zX19+xWN-SXW2k@mail.gmail.com>
	<AANLkTimC5EN9xCDPqszM_L68OoWp_PMYZUGASwyqYx2E@mail.gmail.com>
	<AANLkTikGQSs1VHuPOC838uAHx-BvEg3Sezees-2yrTEQ@mail.gmail.com>
	<AANLkTikGYV5kb6gU7NZf7NxHi9446o1k_Rtcvf1Qwc4_@mail.gmail.com>
Message-ID: <AANLkTikBG68O8qDcJRybf2xXoVC+6uCuLPu1rifm3gbh@mail.gmail.com>

Thank you, Hans. It works perfectly now.

Andrei

On Sat, Jan 22, 2011 at 1:54 AM, Hans H?bner <hans.huebner at gmail.com> wrote:
> On Sat, Jan 22, 2011 at 12:45 AM, AVS <lispercat at gmail.com> wrote:
>> Now it displays on the web page:
>> Internal Server Error
>> An error has occured
>
> This is the right thing. ?You can set *SHOW-LISP-ERRORS-P* to display
> the error to the client, and *LOG-LISP-ERRORS-P* to log them to the
> log file.
>
>> If ?(setf hunchentoot:*handle-http-errors-p* nil) it just says "An
>> error has occured".
>
> *HANDLE-HTTP-ERRORS-P* is not relevant here, I think. ?At least I did
> not intend to modify its behavior.
>
>> Still doesn't trigger the debugger when (setf
>> *catch-errors-p* nil).
>
> http://bknr.net/trac/changeset/4638/trunk fixes this. ?Please update
> and try again.
>
> -Hans
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From dlw at itasoftware.com  Mon Jan 24 21:19:38 2011
From: dlw at itasoftware.com (Daniel Weinreb)
Date: Mon, 24 Jan 2011 16:19:38 -0500
Subject: [hunchentoot-devel] Logging API and default behavior changed
In-Reply-To: <AANLkTi=3S4b-keu0bFiNg2C2NhpL_JyVrX9sL_GXePfd@mail.gmail.com>
References: <AANLkTi=3S4b-keu0bFiNg2C2NhpL_JyVrX9sL_GXePfd@mail.gmail.com>
Message-ID: <4D3DECEA.5060905@itasoftware.com>

Hans,

Hans H?bner wrote:
> Hi,
>
> I have made an incompatible change to Hunchentoot's logging API
> (http://bknr.net/trac/changeset/4639).
>
> To sum up:  The old special variables to configure the log paths as
> well as the -logger slots in the acceptors are gone.  Instead,
> Hunchentoot now has per-acceptor slots containing the log pathnames,
> if any.  Logging is performed by calling the ACCEPTOR-LOG-ACCESS and
> ACCEPTOR-LOG-MESSAGE generic functions that can be specialized for
> derived logger classes.
>   
Definitely a good change.

Just to make sure, the old special variables only
mattered if you used the default logger functions,
right?  In our system, we always provide our
own logger functions, so those special variables
were not used, as far as I know.

The per-acceptor slots containing the log pathnames
are used by the default methods, and are available
for custom (subclass) methods, but have no effect
if you provide your own methods that do not use them,
right?

I'm just checking to be sure.

-- Dan
> Previously, it was possible to disable logging altogether by setting
> the log pathnames to NIL, which also was the default.  I have changed
> that so that if a log pathname is NIL, the log entry is written to
> CL:*ERROR-OUTPUT* instead.  This seems to be a more helpful behavior.
> If an application desires to switch off logging completely, it now
> needs to either set the log pathnames to "/dev/null" (wasteful, but
> quick) or implement methods for the logging functions above.
>
> Please let me know if there are any problems with this change, apart
> from the incompatibility.
>
> -Hans
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>   



From hans.huebner at gmail.com  Mon Jan 24 21:32:27 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Mon, 24 Jan 2011 22:32:27 +0100
Subject: [hunchentoot-devel] Logging API and default behavior changed
In-Reply-To: <4D3DECEA.5060905@itasoftware.com>
References: <AANLkTi=3S4b-keu0bFiNg2C2NhpL_JyVrX9sL_GXePfd@mail.gmail.com>
	<4D3DECEA.5060905@itasoftware.com>
Message-ID: <AANLkTi=w4b+2cusGJ14xFddCnHPA=bTROnCG5_wgf2ev@mail.gmail.com>

On Mon, Jan 24, 2011 at 10:19 PM, Daniel Weinreb <dlw at itasoftware.com> wrote:

> Just to make sure, the old special variables only
> mattered if you used the default logger functions,
> right? ?In our system, we always provide our
> own logger functions, so those special variables
> were not used, as far as I know.

Correct.

> The per-acceptor slots containing the log pathnames
> are used by the default methods, and are available
> for custom (subclass) methods, but have no effect
> if you provide your own methods that do not use them,
> right?

That is correct as well.  While implementing the change, I have
actually pondered the possibility of creating a mixin class for the
logging behavior or create a logger class right away, but found that
to be of little immediate value given that the acceptor class has
several other slots that are useful only in certain operating modes.

-Hans



From sebyte at smolny.plus.com  Sat Jan 29 12:03:44 2011
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Sat, 29 Jan 2011 12:03:44 +0000
Subject: [hunchentoot-devel] Hunchentoot sessions
Message-ID: <mxmjlxwf.fsf@chimera.gnukahvesi.net>

Hi all,

I tried my hand at using sessions for the first time last year, and wrote the
following notes in the process.

---8<------8<------8<------8<------8<------8<------8<------8<------8<---

 ;;; Hunchentoot sessions are one-to-one associations between in-memory CLOS
 ;;; objects and the (unique) value of any incoming session cookie (a cookie
 ;;; with a particular name).  In short, whenever there's an incoming session
 ;;; cookie, if there's a corresponding in-memory CLOS object then a session is
 ;;; taking place and *SESSION* is automatically bound to the CLOS object.

 ;;; Ending a session is therefore simply a case of deleting the in-memory CLOS
 ;;; object, and starting a session is a case of arranging for a new session
 ;;; cookie to be dispatched and creating a corresponding CLOS object.

 ;;; Nothing is sent over HTTP until the execution of a handler is complete,
 ;;; including cookies.  Imagine for a moment that you want to end the current
 ;;; session and start a new one.  Somewhere near the beginning of your handler
 ;;; you delete the CLOS object that represents the current session, arrange
 ;;; for a new cookie to be dispatched and create a new matching CLOS object.
 ;;; You then begin filling the new CLOS object with data until there comes a
 ;;; point when you decide you want to perform a redirect, thus aborting the
 ;;; execution of your handler before it's complete.

 ;;; How should hunchentoot handle this situation?  If you perform the redirect
 ;;; the new cookie will never be sent and the data in your CLOS object is
 ;;; effectively lost.  Should hunchentoot somehow arrange for the same cookie
 ;;; to be sent with the next reply?  Should it refuse to perform the redirect?

 ;;; Hunchentoot's answer is to avoid this situation altogether by not adding
 ;;; CLOS objects to the session database until their corresponding cookies
 ;;; have actually been sent.  In practice this means that you can't delete the
 ;;; current session and create a new one within the lifetime of a single
 ;;; handler.

---8<------8<------8<------8<------8<------8<------8<------8<------8<---

Are they accurate?  I'm not at all sure about the last three paragraphs.

Seb
--
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From hans.huebner at gmail.com  Sun Jan 30 08:23:31 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sun, 30 Jan 2011 09:23:31 +0100
Subject: [hunchentoot-devel] Hunchentoot sessions
In-Reply-To: <mxmjlxwf.fsf@chimera.gnukahvesi.net>
References: <mxmjlxwf.fsf@chimera.gnukahvesi.net>
Message-ID: <AANLkTimP8sHgFGYyxhSkuXAK-Lt05-LsBf_RN4+PVW4D@mail.gmail.com>

Hello Sebastian,

before putting effort into reviewing Hunchentoot's session handling
functionality, I would like to discuss your request:

Am I right in understanding that you are calling REMOVE-SESSION and
START-SESSION in one request, and that you're not seeing correct
results?  Or rather, are you calling REMOVE-SESSION and then REDIRECT
and don't see the results?  Is there a reason why you (seem to) need a
fresh session rather than just changing the session variable that your
application uses?

It would be helpful if you could formulate your problem in terms of a
bug report and include steps to reproduce the behavior.

Thanks,
Hans

On Sat, Jan 29, 2011 at 1:03 PM, Sebastian Tennant
<sebyte at smolny.plus.com> wrote:
> Hi all,
>
> I tried my hand at using sessions for the first time last year, and wrote the
> following notes in the process.
>
> ---8<------8<------8<------8<------8<------8<------8<------8<------8<---
>
> ?;;; Hunchentoot sessions are one-to-one associations between in-memory CLOS
> ?;;; objects and the (unique) value of any incoming session cookie (a cookie
> ?;;; with a particular name). ?In short, whenever there's an incoming session
> ?;;; cookie, if there's a corresponding in-memory CLOS object then a session is
> ?;;; taking place and *SESSION* is automatically bound to the CLOS object.
>
> ?;;; Ending a session is therefore simply a case of deleting the in-memory CLOS
> ?;;; object, and starting a session is a case of arranging for a new session
> ?;;; cookie to be dispatched and creating a corresponding CLOS object.
>
> ?;;; Nothing is sent over HTTP until the execution of a handler is complete,
> ?;;; including cookies. ?Imagine for a moment that you want to end the current
> ?;;; session and start a new one. ?Somewhere near the beginning of your handler
> ?;;; you delete the CLOS object that represents the current session, arrange
> ?;;; for a new cookie to be dispatched and create a new matching CLOS object.
> ?;;; You then begin filling the new CLOS object with data until there comes a
> ?;;; point when you decide you want to perform a redirect, thus aborting the
> ?;;; execution of your handler before it's complete.
>
> ?;;; How should hunchentoot handle this situation? ?If you perform the redirect
> ?;;; the new cookie will never be sent and the data in your CLOS object is
> ?;;; effectively lost. ?Should hunchentoot somehow arrange for the same cookie
> ?;;; to be sent with the next reply? ?Should it refuse to perform the redirect?
>
> ?;;; Hunchentoot's answer is to avoid this situation altogether by not adding
> ?;;; CLOS objects to the session database until their corresponding cookies
> ?;;; have actually been sent. ?In practice this means that you can't delete the
> ?;;; current session and create a new one within the lifetime of a single
> ?;;; handler.
>
> ---8<------8<------8<------8<------8<------8<------8<------8<------8<---
>
> Are they accurate? ?I'm not at all sure about the last three paragraphs.
>
> Seb
> --
> Emacs' AlsaPlayer - Music Without Jolts
> Lightweight, full-featured and mindful of your idyllic happiness.
> http://home.gna.org/eap
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From hans.huebner at gmail.com  Sun Jan 30 10:49:07 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sun, 30 Jan 2011 11:49:07 +0100
Subject: [hunchentoot-devel] HTTP 500 error handling behavior
	customization
In-Reply-To: <AANLkTimjnonip35gY7Q7Un9AHDx7nBM=GapHjac0hWFu@mail.gmail.com>
References: <AANLkTikdCggSqstaZhHvvfpc+UoxRh=WecT=3OS1xxLs@mail.gmail.com>
	<AANLkTimjnonip35gY7Q7Un9AHDx7nBM=GapHjac0hWFu@mail.gmail.com>
Message-ID: <AANLkTi=YH6i-koibxQMsudzBr+HVnHBi0JuoLmHAPzc3@mail.gmail.com>

Hi Blond,

I'm sorry for not having responded to your proposed patch earlier.
With my recent changes to Hunchentoot's error handling, your patch
won't apply cleanly anymore.  I will review it and come up with some
functionality similar to what your patch implemented.

-Hans

On Sun, Oct 17, 2010 at 9:53 AM, Blond BF <blondbf at gmail.com> wrote:
> 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 <blondbf at gmail.com> 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:
>> ...
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From kiuma72 at gmail.com  Mon Jan 31 09:43:51 2011
From: kiuma72 at gmail.com (Andrea Chiumenti)
Date: Mon, 31 Jan 2011 09:43:51 +0000
Subject: [hunchentoot-devel] timeout errors
Message-ID: <AANLkTim6SmUhz+i69-NUdPrJ=w0ypYPQQmHDrb1QREdk@mail.gmail.com>

Hello, I'm using hunchentoot v 1.1.1
and after serving each request I always have errors like this one:

[2011-01-31 10:39:13 [ERROR]] Error while processing connection: I/O timeout
while doing input on #<SB-SYS:FD-STREAM for "socket 127.0.0.1:4242, peer:
127.0.0.1:45423" {100396FEC1}>.


Why the connection isn't properly closed ?

Thanks in advance,
kiuma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20110131/f5d99710/attachment.html>

From hans.huebner at gmail.com  Mon Jan 31 10:01:21 2011
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Mon, 31 Jan 2011 11:01:21 +0100
Subject: [hunchentoot-devel] timeout errors
In-Reply-To: <AANLkTim6SmUhz+i69-NUdPrJ=w0ypYPQQmHDrb1QREdk@mail.gmail.com>
References: <AANLkTim6SmUhz+i69-NUdPrJ=w0ypYPQQmHDrb1QREdk@mail.gmail.com>
Message-ID: <AANLkTin-6cWA3Zk0ueDqEVQL-_pbzSHtYfr5K4n-OoPV@mail.gmail.com>

On Mon, Jan 31, 2011 at 10:43 AM, Andrea Chiumenti <kiuma72 at gmail.com> wrote:
> Hello, I'm using hunchentoot v 1.1.1
> and after serving each request I always have errors like this one:
>
> [2011-01-31 10:39:13 [ERROR]] Error while processing connection: I/O timeout
> while doing input on #<SB-SYS:FD-STREAM for "socket 127.0.0.1:4242, peer:
> 127.0.0.1:45423" {100396FEC1}>.
>
> Why the connection isn't properly closed ?

Do you use the latest version of usocket?  We fixed this problem quite
some time ago.  The message is hamless.  It indicates that the timeout
that Hunchentoot establishes for data arriving on incoming connections
has expired.  The timeout condition should be signalled by usocket as
a portable condition and will then be handled by Hunchentoot properly
(silently).  If you are using an outdated usocket release, the
condition will be signalled in non-portable form, not be caught by
Hunchentoot and then logged as an error.

-Hans



From kiuma72 at gmail.com  Mon Jan 31 10:29:24 2011
From: kiuma72 at gmail.com (Andrea Chiumenti)
Date: Mon, 31 Jan 2011 10:29:24 +0000
Subject: [hunchentoot-devel] timeout errors
In-Reply-To: <AANLkTin-6cWA3Zk0ueDqEVQL-_pbzSHtYfr5K4n-OoPV@mail.gmail.com>
References: <AANLkTim6SmUhz+i69-NUdPrJ=w0ypYPQQmHDrb1QREdk@mail.gmail.com>
	<AANLkTin-6cWA3Zk0ueDqEVQL-_pbzSHtYfr5K4n-OoPV@mail.gmail.com>
Message-ID: <AANLkTikqGiVtm6k0VZT7XjPniUrjLy1VHnvjGKiygnQi@mail.gmail.com>

Hello Hans
I was using the version provided by gentoo that is the 0.4.1.  Now I'm using
the svn version and it works as expected. I thought that a release was done.

Thanks for the reply
kiuma

2011/1/31 Hans H?bner <hans.huebner at gmail.com>

> On Mon, Jan 31, 2011 at 10:43 AM, Andrea Chiumenti <kiuma72 at gmail.com>
> wrote:
> > Hello, I'm using hunchentoot v 1.1.1
> > and after serving each request I always have errors like this one:
> >
> > [2011-01-31 10:39:13 [ERROR]] Error while processing connection: I/O
> timeout
> > while doing input on #<SB-SYS:FD-STREAM for "socket 127.0.0.1:4242,
> peer:
> > 127.0.0.1:45423" {100396FEC1}>.
> >
> > Why the connection isn't properly closed ?
>
> Do you use the latest version of usocket?  We fixed this problem quite
> some time ago.  The message is hamless.  It indicates that the timeout
> that Hunchentoot establishes for data arriving on incoming connections
> has expired.  The timeout condition should be signalled by usocket as
> a portable condition and will then be handled by Hunchentoot properly
> (silently).  If you are using an outdated usocket release, the
> condition will be signalled in non-portable form, not be caught by
> Hunchentoot and then logged as an error.
>
> -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: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20110131/45559868/attachment.html>