You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeremy Devenport <je...@weezel.com> on 2000/03/02 05:25:39 UTC
[PATCH] Extra CRLF in chunked response
I'm really new to the Apache 2.0 code base but it looks like an extra
CRLF is being sent after the trailer chunk.
Jeremy Devenport
--- http_protocol.c 2000/01/31 19:21:37 1.53
+++ http_protocol.c 2000/03/02 04:22:04
@@ -1667,7 +1667,6 @@
ap_rputs("0\015\012", r);
/* If we had footer "headers", we'd send them now */
- ap_rputs("\015\012", r);
}
}
Re: [PATCH] Extra CRLF in chunked response
Posted by Jeremy Devenport <je...@weezel.com>.
No, I was definitely wrong, it's supposed to be there.
Jeremy
"William A. Rowe, Jr." wrote:
>
> > I'm really new to the Apache 2.0 code base but it looks like an extra
> > CRLF is being sent after the trailer chunk.
> >
> > Jeremy Devenport
> >
> > --- http_protocol.c 2000/01/31 19:21:37 1.53
> > +++ http_protocol.c 2000/03/02 04:22:04
> > @@ -1667,7 +1667,6 @@
> >
> > ap_rputs("0\015\012", r);
> > /* If we had footer "headers", we'd send them now */
> > - ap_rputs("\015\012", r);
> > }
> > }
>
> Yes - except that the extra crlf's occur prior to the 0<cr><lf> last chuck
> indicator. Perhaps you point out an additional problem, but I don't believe
> the browsers ever get this far.
Re: chunked encoding
Posted by 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
Posted by 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
Posted by 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
RE: [Not yet a PATCH] Extra CRLF in chunked response
Posted by "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: [PATCH] Extra CRLF in chunked response
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> I'm really new to the Apache 2.0 code base but it looks like an extra
> CRLF is being sent after the trailer chunk.
>
> Jeremy Devenport
>
> --- http_protocol.c 2000/01/31 19:21:37 1.53
> +++ http_protocol.c 2000/03/02 04:22:04
> @@ -1667,7 +1667,6 @@
>
> ap_rputs("0\015\012", r);
> /* If we had footer "headers", we'd send them now */
> - ap_rputs("\015\012", r);
> }
> }
Yes - except that the extra crlf's occur prior to the 0<cr><lf> last chuck
indicator. Perhaps you point out an additional problem, but I don't believe
the browsers ever get this far.
Re: [PATCH] Extra CRLF in chunked response
Posted by Greg Stein <gs...@lyra.org>.
On Wed, 1 Mar 2000, Jeremy Devenport wrote:
> I'm really new to the Apache 2.0 code base but it looks like an extra
> CRLF is being sent after the trailer chunk.
>
> Jeremy Devenport
>
> --- http_protocol.c 2000/01/31 19:21:37 1.53
> +++ http_protocol.c 2000/03/02 04:22:04
> @@ -1667,7 +1667,6 @@
>
> ap_rputs("0\015\012", r);
> /* If we had footer "headers", we'd send them now */
> - ap_rputs("\015\012", r);
> }
> }
The spec for the chunked-transfer encoding is at:
http://andrew2.andrew.cmu.edu/rfc/rfc2616.html#sec-3.6.1
As you can see, the "last-chunk" symbol is "0" CRLF. This is followed by a
set of "trailer" entries. Finally, a CRLF terminates the entire transfer.
Therefore, the above code is correct.
I thought I saw this same problem in 1.3 when I wrote some
chunked-transfer client code, almost sent some mail, but then reviewed the
spec one more time...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/