- From: Willy Tarreau <w@1wt.eu>
- Date: Sat, 25 Jun 2011 00:14:10 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
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