[flexi-streams-devel] Re: [hunchentoot-devel] write-sequence to *hunchentoot-stream* on x86_64
Edi Weitz
edi at agharta.de
Tue Aug 21 09:54:26 UTC 2007
On Mon, 20 Aug 2007 12:47:06 -0700 (PDT), Jeff Caldwell <jdcal at yahoo.com> wrote:
> Can anyone give me a way to debug the following problem, or tell me
> likely places to investigate?
>
> With Hunchentoot 0.11.1 I have a problem on this machine:
>
> Linux machine-1-name 2.6.18-8.1.8.el5 #1 SMP Mon Jun 25 15:19:07 EDT 2007
> x86_64 x86_64 x86_64 GNU/Linux
>
> but I don't have that problem on this machine:
>
> Linux machine-2-name 2.6.16.27-0.9-smp #1 SMP Tue Feb 13 09:35:18 UTC 2007
> i686 i686 i386 GNU/Linux
>
> I am running LWL Pro 4.3.7.
>
> On the x86_64 machine, every page, even the Hunchentoot default
> page, has some seemingly-random binary data that comes after the
> headers but before the content. This appears in the browser as
> strange characters at the top of the page, often (but not always)
> followed by part or all of the desired web page. The random binary
> data is not in the content variable that is written to the
> stream. The headers are OK, the content is OK, it is only that there
> is extra binary data between the headers and the content.
>
> I found a workaround. In headers.lisp, in function start-output, in
> the following code, write-sequence is the original code in
> hunchentoot while write-string is the workaround needed to get good
> output and avoid the extraneous binary data between the headers and
> the content.
>
> ...
> (setf (flexi-stream-external-format *hunchentoot-stream*)
> (reply-external-format))
> ;; now optional content
> (unless (or (null content) head-request-p)
> (ignore-errors
> #+x86_64RHEL5-workaround
> (write-string (coerce (loop for c across content
> collect (code-char c)) 'string)
>
> *hunchentoot-stream*)
> #-x86_64RHEL5-workaround
> (write-sequence content *hunchentoot-stream*)))
> (when chunkedp
> ;; turn chunking on after the headers have been sent
> (setf (chunked-stream-output-chunking-p
> (flexi-stream-stream *hunchentoot-stream*)) t))
> *hunchentoot-stream*))
>
> Again, can anyone give me tips on where to look or how to debug the
> problem?
Looks like a possible bug in flexi-streams (/or/ in LWL 4) to me and
should probably be discussed on the corresponding mailing list - see
Cc. Could you check if the test suite of flexi-streams runs through
on your x86_64 machine? Are you using the newest version of
flexi-streams? Could you check if you get the same problems with LWL
5.0.x, maybe using the Personal Edition? Unfortunately, I don't have
a 64-bit machine yet to check this myself.
Thanks,
Edi.
More information about the Flexi-streams-devel
mailing list