[hunchentoot-devel] Hard to catch errors below process-request

[Hans Hübner]

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
>