httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: [BUG]: "chunk length has blank (0x20) appended" on Solaris 2.x (fwd)
Date Fri, 07 Mar 1997 23:02:39 GMT
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:
> --
> 
> --
> 
> 


Mime
View raw message