Bug 41364 - chunk-size contains space
Summary: chunk-size contains space
Status: CLOSED INVALID
Alias: None
Product: Apache httpd-1.3
Classification: Unclassified
Component: core (show other bugs)
Version: 1.3.34
Hardware: Other other
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-15 01:38 UTC by jfclere
Modified: 2008-08-01 15:31 UTC (History)
0 users



Attachments
cgi to reproduce the problem. (399 bytes, text/plain)
2007-01-15 01:40 UTC, jfclere
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jfclere 2007-01-15 01:38:54 UTC
According to rfc2616 chunck-size should be HEX but httpd-1.3.x pads the HEX
string with spaces.
Comment 1 jfclere 2007-01-15 01:40:09 UTC
Created attachment 19403 [details]
cgi to reproduce the problem.
Comment 2 jfclere 2007-01-15 02:27:49 UTC
Would it make sense to add leading zeros instead padding with spaces?
Comment 3 Jeff Trawick 2007-01-15 09:01:02 UTC
I'm pretty darn sure I raised this issue on dev@httpd a long while ago and one
of the HTTP authors (Roy Fielding) indicated that it was not an issue for some
reason (I don't recall if it was an acknowledged bug in the RFC).

Sadly I can't find the text at the moment.
Comment 4 Joe Orton 2007-01-29 06:27:36 UTC
The padding would at least be permitted by 2616's "implied LWS" rule.  What
problem does this cause?
Comment 5 jfclere 2007-01-29 07:25:54 UTC
chunk-size     = 1*HEX
That doesn't allow padding ;-(

The error has been reported by someone using the http client MS WinINet "that
throws an exception when receiving a space in the chunk-size."
Comment 6 Joe Orton 2007-01-29 09:18:27 UTC
The implied LWS rule in section 2.2 of 2616 allows LWS basically anywhere
without having to explictly specify such in every grammar production.

It looks tricky to fix this in the 1.3 code; if this is just a single buggy
client  there doesn't seem much motivation to mess with the code; just use a
"BrowserMatch blah force-response-1.0" to prevent HTTP/1.1 responses?
Comment 7 jfclere 2007-01-30 02:54:09 UTC
Leading zeros can't be used because they would break rfc2068 (See 3.6 Transfer
Codings):
+++
       chunk          = chunk-size [ chunk-ext ] CRLF
                        chunk-data CRLF

       hex-no-zero    = <HEX excluding "0">

       chunk-size     = hex-no-zero *HEX
+++

The spaces padding the hex value are ok according to rfc2616 (See 2.1 and 2.2)
+++
 implied *LWS
      The grammar described by this specification is word-based. Except
      where noted otherwise, linear white space (LWS) can be included
      between any two adjacent words (token or quoted-string), and
      between adjacent words and separators, without changing the
      interpretation of a field. At least one delimiter (LWS and/or

      separators) MUST exist between any two tokens (for the definition
      of "token" below), since they would otherwise be interpreted as a
      single token.
+++
and:
+++
  HTTP/1.1 header field values can be folded onto multiple lines if the
   continuation line begins with a space or horizontal tab. All linear
   white space, including folding, has the same semantics as SP. A
   recipient MAY replace any linear white space with a single SP before
   interpreting the field value or forwarding the message downstream.

       LWS            = [CRLF] 1*( SP | HT )
+++