[drakma-devel] Clozure CL Page Specific Error

Edi Weitz edi at agharta.de
Tue Jun 10 06:52:46 UTC 2008


On Mon, 9 Jun 2008 22:20:50 -0600, "Wade Humeniuk" <wade.humeniuk at gmail.com> wrote:

> I am having trouble with Clozure CL.  I am not sure this is the
> right mailing list as it seems to be a CCL problem (unexpected
> end-of-file). This same request works with LW 5.0.1 and SBCL 1.0.15
> on the same machine.  CCL also works with other urls like "
> https://bmo.com".  The failing url is being served by an apache web
> server.  I have noticed similiar problems have been posted to this
> mailing list.

I can confirm that this fails for me with ClozureCL and works with
LispWorks.  A short analysis of what I think happens:

1. We're reading from a text stream with UTF-8 encoding.

2. The server tells us the length of the body is 2353 octets.

3. Drakma creates a string of length 2353.  With UTF-8, the string
   could be shorter, but you can't be sure before you've read it.

4. It then calls READ-SEQUENCE on this string which is implemented by
   FLEXI-STREAMS.

5. FLEXI-STREAMS, knowing that this is UTF-8 and /not/ knowing that
   there can be at most 2353 octets (2353 /characters/ are asked for)
   tries to read a bit more.  It tries to read 2355 octets from the
   underlying binary stream.

6. The underlying stream is a Chunga stream, but as there's no chunked
   encoding involved, READ-SEQUENCE is directly invoked on the SSL
   stream.

7. That's where the error happens.

My understanding is that if you're trying to READ-SEQUENCE 2355 octets
and there's an EOF after 2353 octets, then READ-SEQUENCE should read
these 2353 octets and return the position as described by the ANSI
standard.  I don't think it is correct that ClozureCL signals an error
here.  You should probably ask on their mailing list.  (Does this also
happen with HTTP instead of HTTPS?  Maybe it's a problem with the
CL+SSL library?)

A workaround would be to send the request with :FORCE-BINARY T and to
convert the content yourself which is admittedly a kludge.

Having said that, this is actually due to the way READ-SEQUENCE is
implemented in newer versions of FLEXI-STREAMS.  Now that
FLEXI-STREAMS has an efficient version of OCTETS-TO-STRING, I'm
wondering if it would make sense if Drakma always read the sequence as
binary data and then called OCTETS-TO-STRING on the result if needed.
Comments?

Cheers,
Edi.



More information about the Drakma-devel mailing list