You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rob Hartill <ro...@imdb.com> on 1998/01/02 19:21:58 UTC
Bug in chunked encoding in Apache 1.2.4 (fwd)
---------- Forwarded message ----------
Date: Wed, 31 Dec 1997 18:08:15 -0500
From: Henrik Frystyk Nielsen <fr...@w3.org>
To: apache-bugs@apache.org
Subject: Bug in chunked encoding in Apache 1.2.4
I believe I have found a bug in the Apache chunked encoding code which
makes my robot [1] rather confused as it misses the End Of Message marker
in a pipelined stream.
The problem is that parts of a chunked length line and the data following
gets overwritten with spaces. Check out this sample, which I consistently
run into (obtained using tcpshow on the trace that I give a pointer to
below). Although it doesn't look like it, it's the response to three
different URLs on the http://www.w3.org server (my comments are to the
right (<-):
HTTP/1.1 302 Moved Temporarily. <- First Response (OK)
Date: Wed, 31 Dec 1997 20:44:08 GMT.
Server: Apache/1.2.4.
Location: http://www.w3.org/Jigsaw/User/api/w3c.cvs.CVS.html.
Transfer-Encoding: chunked.
Content-Type: text/html.
.
cb .
<HTML><HEAD>
<TITLE>302 Moved Temporarily</TITLE>
</HEAD><BODY>
<H1>Moved Temporarily</H1>
The document has moved <A
HREF="http://www.w3.org/Jigsaw/User/api/w3c.cvs.CVS.html">here</A>.<P>
</BODY></HTML>
.
0.
.
HTTP/1.1 302 Moved Temporarily. <- Second response
Date: Wed, 31 Dec 1997 20:44:08 GMT.
Server: Apache/1.2.4.
Location: http://www.w3.org/Jigsaw/User/api/w3c.cvs.CVS.html.
Transfer-Encoding: chunked.
Content-Type: text/html.
.
-----------------------------------------------------------------
18.23.0.23.80 -> 18.29.0.26.36954 over TCP
cb . <- Note the 10 extra spaces
<TITLE>302 Moved Temporarily</TITLE> <- Note the missing <HTML>
</HEAD><BODY> <- and <HEAD> (10 chars).
<H1>Moved Temporarily</H1>
The document has moved <A
HREF="http://www.w3.org/Jigsaw/User/api/w3c.cvs.CVS.html">here</A>.<P>
</BODY></HTML>
.
0.
.
HTTP/1.1 200 OK.
Date: Wed, 31 Dec 1997 20:44:08 GMT.
Server: Apache/1.2.4.
Last-Modified: Thu, 31 Jul 1997 11:23:58 GMT.
ETag: "2d719e-54ed-33e075ce".
Content-Length: 21741.
Accept-Ranges: bytes.
Content-Type: text/html; charset=ISO-8859-1.
.
I have to the complete tcpdump output available at
http://www.w3.org/Protocols/HTTP/Performance/Apache/apache.tcpdump
One other thing, what is the reason for a default value of 100 requests pr.
TCP connection? I would have chosen at least 500.
Hope this helps,
Henrik
[1] http://www.w3.org/Library/
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk
Re: Bug in chunked encoding in Apache 1.2.4 (fwd)
Posted by Henrik Frystyk Nielsen <fr...@w3.org>.
At 11:07 1/2/98 -0800, Dean Gaudet wrote:
Hi Dean,
>Spaces are permitted after the chunked length, you know that right?
Yes, that's not a problem in my code - it accepts both spaces and
parameters although I have never seen anybody generating the latter.
>Apache does generate them (because it guesses how much space it will need
>to write the length, and then goes back later to fill it in and fills with
>trailing spaces), but this does look wrong.
That makes sense, I just noted that the 10 extra spaces that was not
present in the first response seems to be the 10 missing characters of the
chunk data.
>Are you using a special html module that's using rputc() to send output?
>There's a definate bug in rputc() but I'm not sure it can be triggered
>easily in 1.2.x (whereas in 1.3b3 it happens quite easily). Maybe you can
>try this patch?
I am using straight 1.2.4 out of the box. Is the patch for 1.2.4 or 1.3b3
or does it matter?
Thanks and a happy newyear!
Henrik
PS: I am working from home today but I will try it out tomorrow.
--
Henrik Frystyk Nielsen, <fr...@w3.org>
World Wide Web Consortium
http://www.w3.org/People/Frystyk
Re: Bug in chunked encoding in Apache 1.2.4 (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
Henrik tells me this appears to fix the bug he's seeing with 1.2.
Dean
On Fri, 2 Jan 1998, Dean Gaudet wrote:
> Hi Henrik,
>
> Spaces are permitted after the chunked length, you know that right?
> Apache does generate them (because it guesses how much space it will need
> to write the length, and then goes back later to fill it in and fills with
> trailing spaces), but this does look wrong.
>
> Are you using a special html module that's using rputc() to send output?
> There's a definate bug in rputc() but I'm not sure it can be triggered
> easily in 1.2.x (whereas in 1.3b3 it happens quite easily). Maybe you can
> try this patch?
>
> Dean
>
> Index: buff.c
> ===================================================================
> RCS file: /export/home/cvs/apache/src/buff.c,v
> retrieving revision 1.26.2.1
> diff -u -r1.26.2.1 buff.c
> --- buff.c 1997/08/07 08:41:46 1.26.2.1
> +++ buff.c 1998/01/02 19:01:27
> @@ -584,9 +584,16 @@
> bflsbuf(int c, BUFF *fb)
> {
> char ss[1];
> + int rc;
>
> ss[0] = c;
> - return bwrite(fb, ss, 1);
> + rc = bwrite(fb, ss, 1);
> + /* We do start_chunk() here so that the bputc macro can be smaller
> + * and faster
> + */
> + if (rc == 1 && (fb->flags & B_CHUNK))
> + start_chunk(fb);
> + return rc;
> }
>
> /*
>
>
>
>
Re: Bug in chunked encoding in Apache 1.2.4 (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
Hi Henrik,
Spaces are permitted after the chunked length, you know that right?
Apache does generate them (because it guesses how much space it will need
to write the length, and then goes back later to fill it in and fills with
trailing spaces), but this does look wrong.
Are you using a special html module that's using rputc() to send output?
There's a definate bug in rputc() but I'm not sure it can be triggered
easily in 1.2.x (whereas in 1.3b3 it happens quite easily). Maybe you can
try this patch?
Dean
Index: buff.c
===================================================================
RCS file: /export/home/cvs/apache/src/buff.c,v
retrieving revision 1.26.2.1
diff -u -r1.26.2.1 buff.c
--- buff.c 1997/08/07 08:41:46 1.26.2.1
+++ buff.c 1998/01/02 19:01:27
@@ -584,9 +584,16 @@
bflsbuf(int c, BUFF *fb)
{
char ss[1];
+ int rc;
ss[0] = c;
- return bwrite(fb, ss, 1);
+ rc = bwrite(fb, ss, 1);
+ /* We do start_chunk() here so that the bputc macro can be smaller
+ * and faster
+ */
+ if (rc == 1 && (fb->flags & B_CHUNK))
+ start_chunk(fb);
+ return rc;
}
/*