| Summary: | chunk-size contains space | ||
|---|---|---|---|
| Product: | Apache httpd-1.3 | Reporter: | jfclere <jfclere> |
| Component: | core | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | CLOSED INVALID | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | 1.3.34 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | other | ||
| Attachments: | cgi to reproduce the problem. | ||
|
Description
jfclere
2007-01-15 01:38:54 UTC
Created attachment 19403 [details]
cgi to reproduce the problem.
Would it make sense to add leading zeros instead padding with spaces? 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. The padding would at least be permitted by 2616's "implied LWS" rule. What problem does this cause? 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." 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? 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 )
+++
|