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 1997/03/07 21:02:49 UTC
[BUG]: "chunk length has blank (0x20) appended" on Solaris 2.x (fwd)
not acked.
---------- Forwarded message ----------
Date: Fri Mar 7 11:50:16 1997
From: udeupct@lexis-nexis.com
To: apache-bugs%apache.org@organic.com
Subject: [BUG]: "chunk length has blank (0x20) appended" on Solaris 2.x
Submitter: udeupct@lexis-nexis.com
Operating system: Solaris 2.x, version:
Version of Apache Used: 1.2b7
Extra Modules used: digest, fastcgi, status, info
URL exhibiting problem:
Symptoms:
--
A response is returned with Transfer-Encoding: chunked.
The chunksize has a blank (0x20) appended to it,
which causes some client software to report it as
an invalid length.
Here's the output from snoop on the packet:
48: 2238 36bb 0000 4854 5450 2f31 2e31 2032 "86...HTTP/1.1 2
64: 3030 204f 4b0d 0a44 6174 653a 2054 6875 00 OK..Date: Thu
80: 2c20 3036 204d 6172 2031 3939 3720 3232 , 06 Mar 1997 22
96: 3a32 363a 3538 2047 4d54 0d0a 5365 7276 :26:58 GMT..Serv
112: 6572 3a20 4170 6163 6865 2f31 2e32 6237 er: Apache/1.2b7
128: 0d0a 436f 6e6e 6563 7469 6f6e 3a20 4b65 ..Connection: Ke
144: 6570 2d41 6c69 7665 0d0a 4b65 6570 2d41 ep-Alive..Keep-A
160: 6c69 7665 3a20 7469 6d65 6f75 743d 3135 live: timeout=15
176: 2c20 6d61 783d 3130 300d 0a54 7261 6e73 , max=100..Trans
192: 6665 722d 456e 636f 6469 6e67 3a20 6368 fer-Encoding: ch
208: 756e 6b65 640d 0a43 6f6e 7465 6e74 2d54 unked..Content-T
224: 7970 653a 2061 7070 6c69 6361 7469 6f6e ype: application
240: 2f6f 6374 6574 2d73 7472 6561 6d0d 0a43 /octet-stream..C
256: 6f6e 7465 6e74 2d6c 656e 6774 683a 2036 ontent-length: 6
272: 320d 0a0d 0a33 6520 0d0a 0000 0000 0007 2....3e ........
^^^^ ^^^^ ^^^^ ^^^^
The chunk length should just be 33 65.
While this is legal according to the spec (which
only prohibits 0x0), it nevertheless is unexpected
at best and can cause core dumps at worst. One of
the mails regarding transfer encoding at w3c.org
(http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q4/0088.html)
says that we should just convert the chunk size
with strtol. The chunksize given above causes
strtol to core dump (solaris 2.5).
Unfortunately I am unable to locate a browser which
is HTTP 1.1 compliant to duplicate the problem.
--
Backtrace:
--
--
Re: [BUG]: "chunk length has blank (0x20) appended" on Solaris 2.x (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
Unfortunately this is both necessary and expected. As you say, it's valid
according to the standard. You'll notice that the standard explicitly
does not allow a leading 0 on the chunk size.
Apache emits this extra space because it is attempting to avoid both extra
memory copies and gratuitous socket write()s. Essentially when it starts
a chunk it reserves enough room to fit the chunksize for the maximum sized
chunk that it could put in the current buffer. When the chunk is finished
it goes back and corrects the guess it made... and if the new number it
needs to write is shorter than expected it puts in trailing spaces.
If strtol coredumps on that it's really a Solaris bug. That's a valid
string, strtol is supposed to stop at the first non-valid character,
and store a pointer to that in *endptr if endptr is not null. (And that
is probably specified ANSI/POSIX...)
Dean
On Fri, 7 Mar 1997, Rob Hartill wrote:
>
>
> not acked.
>
> ---------- Forwarded message ----------
> Date: Fri Mar 7 11:50:16 1997
> From: udeupct@lexis-nexis.com
> To: apache-bugs%apache.org@organic.com
> Subject: [BUG]: "chunk length has blank (0x20) appended" on Solaris 2.x
>
> Submitter: udeupct@lexis-nexis.com
> Operating system: Solaris 2.x, version:
> Version of Apache Used: 1.2b7
> Extra Modules used: digest, fastcgi, status, info
> URL exhibiting problem:
>
> Symptoms:
> --
> A response is returned with Transfer-Encoding: chunked.
> The chunksize has a blank (0x20) appended to it,
> which causes some client software to report it as
> an invalid length.
>
> Here's the output from snoop on the packet:
>
> 48: 2238 36bb 0000 4854 5450 2f31 2e31 2032 "86...HTTP/1.1 2
> 64: 3030 204f 4b0d 0a44 6174 653a 2054 6875 00 OK..Date: Thu
> 80: 2c20 3036 204d 6172 2031 3939 3720 3232 , 06 Mar 1997 22
> 96: 3a32 363a 3538 2047 4d54 0d0a 5365 7276 :26:58 GMT..Serv
> 112: 6572 3a20 4170 6163 6865 2f31 2e32 6237 er: Apache/1.2b7
> 128: 0d0a 436f 6e6e 6563 7469 6f6e 3a20 4b65 ..Connection: Ke
> 144: 6570 2d41 6c69 7665 0d0a 4b65 6570 2d41 ep-Alive..Keep-A
> 160: 6c69 7665 3a20 7469 6d65 6f75 743d 3135 live: timeout=15
> 176: 2c20 6d61 783d 3130 300d 0a54 7261 6e73 , max=100..Trans
> 192: 6665 722d 456e 636f 6469 6e67 3a20 6368 fer-Encoding: ch
> 208: 756e 6b65 640d 0a43 6f6e 7465 6e74 2d54 unked..Content-T
> 224: 7970 653a 2061 7070 6c69 6361 7469 6f6e ype: application
> 240: 2f6f 6374 6574 2d73 7472 6561 6d0d 0a43 /octet-stream..C
> 256: 6f6e 7465 6e74 2d6c 656e 6774 683a 2036 ontent-length: 6
> 272: 320d 0a0d 0a33 6520 0d0a 0000 0000 0007 2....3e ........
> ^^^^ ^^^^ ^^^^ ^^^^
>
> The chunk length should just be 33 65.
>
> While this is legal according to the spec (which
> only prohibits 0x0), it nevertheless is unexpected
> at best and can cause core dumps at worst. One of
> the mails regarding transfer encoding at w3c.org
> (http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q4/0088.html)
> says that we should just convert the chunk size
> with strtol. The chunksize given above causes
> strtol to core dump (solaris 2.5).
>
> Unfortunately I am unable to locate a browser which
> is HTTP 1.1 compliant to duplicate the problem.
> --
>
> Backtrace:
> --
>
> --
>
>