RE: [Not yet a PATCH] Extra CRLF in chunked response

["William A. Rowe, Jr." <wr...@lnd.com>]

Ok - this is even odder than I first imagined.  here's a very fragmentary
look at a cgi/pl script I am playing with... the <<< and >>> are my
inventions - the rest is the Apache response.

>>> First Block Follows:
HTTP/1.1 200 OK
Date: Thu, 02 Mar 2000 05:45:35 GMT
Server: Apache/2.0-dev
Transfer-Encoding: chunked
Content-Type: text/html

1fe7

<!DOCTYPE HTML ... PRINTING STEE
<<< End of block - note a CRLF follows after the 1fe7 bytes.
>>> Second Block Follows:
1000

L TO STEEL ...    <TH
<<< End of 2nd block - note a CRLF follows after the 1000 bytes.
>>>Third Block Follows:
1000

><A NAME="....style.display =
<<< End of 3nd block - note a CRLF follows after the 1000 bytes.
>>> Fourth Block Follows, now here it gets WEIRD:
57
'none'; }...</HTML>

<<< End of 4th and final block, CRLF follows after the 57, but wait...
>>> Closing Tag
0

<<< And end of Closing Tag, WORKS AS EXPECTED.

Here is what is SO ODD... the 57 in the 3rd block is followed by 2 spaces
and then a single CRLF, it is NOT followed by a blank line before the block
data!!!

Hope that helps all you bughunters - I'll pick it up tommorow (too tired -
need to do a build with a browser database before I pick back up).

Good luck,

Bill

Re: chunked encoding

[Manoj Kasichainula <ma...@io.com>]

On Thu, Mar 02, 2000 at 01:50:27AM -0800, Dean Gaudet wrote:
> ok could folks retry with current 2.0?  i checked in a fix.

Seems to be working for me, by visual inspection and by testing with
an HTTP/1.1 client.

chunked encoding

[Dean Gaudet <dg...@arctic.org>]

ok could folks retry with current 2.0?  i checked in a fix.

Dean

RE: [Not yet a PATCH] Extra CRLF in chunked response

[Dean Gaudet <dg...@arctic.org>]

On Thu, 2 Mar 2000, William A. Rowe, Jr. wrote:

> Here is what is SO ODD... the 57 in the 3rd block is followed by 2 spaces

that is by design (and is permitted by rfc2068/2616).  rfc2068 didn't
permit us to use leading 0s... although rfc2616 does permit leading 0s i'd
rather not change the behaviour now.

> and then a single CRLF, it is NOT followed by a blank line before the block
> data!!!

there shouldn't be an *extra* blank line at all.  i'm guessing the blank
lines you're seeing are not part of your data?

i think i see what the problem is, and about a dozen other problems.

now i'll just have to go guess what the latest configuration instructions
are so that i can compile the code (it doesn't look like anyone updated
any of the top-level READMEs...)

Dean