According to rfc2616 chunck-size should be HEX but httpd-1.3.x pads the HEX string with spaces.
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 ) +++