[tbnl-devel] Fixing binary uploads in SBCL / TBNL / mod_lisp2
Edi Weitz
edi at agharta.de
Thu Nov 3 23:57:22 UTC 2005
On Thu, 03 Nov 2005 12:13:41 -0500, Travis Cross <travis at crosswirecorp.com> wrote:
> Running SBCL 0.9.6 with TBNL 0.8.4 and Apache 2.0.54 with mod_lisp2,
> the image download examples work as expected,
Hmm, I just tried with SBCL 0.9.6 in TBNL's "stand-alone" mode and
only the first image download example worked for me.
> but uploading any binary file results in a 500 Internal Server Error
> being throw by Apache. No error is reported in Lisp, but the Apache
> log file error_log shows the following entry:
>
> [error] (70014)End of file found: error reading from Lisp
>
> Setting apache to log in debug mode doesn't provide any additional
> insight, but some testing and modification of the mod_lisp2.c code
> showed that the error is starting at line 588 where mod_lisp
> attempts to read the first of the headers. This leads back to
> read_lisp_line(), then deeper to fill_input_buffer(), where the
> failure seems to originate at the call to:
>
> RELAY_ERROR
> (((length = (sizeof (buffer->data))),
> (apr_recv (socket, (buffer->data), (&length)))));
>
> With *DEBUG-MODE* set to t, *COMMAND* contains seemingly plausible
> headers (shown below).
>
> I am not familiar enough with the internals to have much of an idea
> of what is causing the breakdown, though the C code seems to suggest
> that lisp is sending a different amount of data than is promised.
>
> I'm happy to dig into either the TBNL, KMRCL, or mod_lisp2.c code
> and come up with a patch for this, but it would be tremendously
> helpful if someone has a good idea of where to start and what the
> problem might be.
I don't really have an idea but I'd advise you to track this down
without Apache - use TBNL without a back-end. I'm pretty sure the
problem is TBNL not properly supporting SBCL's Unicode branch and it's
not related to Apache or mod_lisp.
You might want to experiment with different locale settings and see if
it makes a difference.
Cheers,
Edi.
More information about the Tbnl-devel
mailing list