httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sameer <sam...@c2.net>
Subject Re: [BUG]: "chunk length has blank (0x20) appended" on Solaris 2.x (fwd)
Date Fri, 07 Mar 1997 21:47:48 GMT
	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