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:04:11 GMT
Nope he's talking about the chunk length... which as I replied
deliberately includes that space. 

Dean

On Fri, 7 Mar 1997, sameer wrote:

> 	is this a bug in ap_snprintf?
> 
> int set_content_length (request_rec *r, long clength)
> {
>     char ts[MAX_STRING_LEN];
> 
>     r->clength = clength;
> 
>     ap_snprintf (ts, sizeof(ts), "%ld", clength);
>     table_set (r->headers_out, "Content-Length", pstrdup (r->pool, ts));
> 
>     return 0;
> }
> 
> 
> > 
> > 
> > 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:
> > --
> > 
> > --
> > 
> 
> 
> -- 
> Sameer Parekh					Voice:   510-986-8770
> President					FAX:     510-986-8777
> C2Net
> http://www.c2.net/				sameer@c2.net
> 


Mime
View raw message