Re: #273: HTTP-Version should be redefined as fixed length pair of DIGIT . DIGIT

Hi Julian,
On Fri, Jun 24, 2011 at 10:16:26PM +0200, Julian Reschke wrote:
> The HTTP version number consists of two non-negative decimal digits
Since "integer" was changed to "digits" here, maybe we can remove the
"non-negative" precision ?
Otherwise the rest is OK to me.
> I also checked for examples that use multiple digits and couldn't find any.
I did a few quick checks on some sources I have here (some being quite outdated) :
 - thttpd : only checks if version string == HTTP/1.0, everything else is 1.1
 - mini-httpd : same
 - tux : checks for minor == 1 (first digit)
 - varnish : compares version string with "HTTP/1.0" and "HTTP/1.1", everything
 else is 0.9.
 - haproxy : sets 1.1 when length == 8 and ((major > 1) or (major == 1 and
 minor >= 1)) (one digit for each part). So 1.10 reports 1.0.
 - apache : does sscanf("%u.%u") and accepts minors up to 999.
 - teepeedee : makes use of strtoul() on both major and minor
 - squid : does sscanf("%d.%d"). Not sure what it does with negatives. This
 was a pretty old version however (2.5-stable12), that might not count.
 - lighttpd : uses strtol() on both major and minor (so might accept negatives)
 but checks for major==1 and minor==1 (or minor==0) to report 1.1 or 1.0
 respectively, the rest being rejected.
 - nginx : I was not sure
Given the diversity of methods, I think it's really nice that we can
simplify the parsing.
Regards,
Willy

Received on Friday, 24 June 2011 22:14:40 UTC

AltStyle によって変換されたページ (->オリジナル) /