W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: HTTP/2: Another reason to find a safer encoding

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 1 Aug 2012 07:43:22 +0200
To: Zhong Yu <zhong.j.yu@gmail.com>
Cc: ietf-http-wg@w3.org
Message-ID: <20120801054322.GA14213@1wt.eu>
On Tue, Jul 31, 2012 at 07:24:12PM -0500, Zhong Yu wrote:
> The problem is that implementations tend to be liberal in accepting
> inputs. That is mostly due to laziness - being strict is harder. As
> long as an input can be mapped to an acceptable value, no harm is done
> to the internal state, therefore there's no incentive for
> implementations to reject illegal inputs. This is the reality, no
> matter how sternly the spec emphasizes the MUST NOTs.

This is not the only issue, it's very hard to be strict on things that
are not well defined. For instance, we had a hard time trying to find
what to do with multiple content-lengths. Some implementers had to
perform some tests to see how much breakage they would cause by becoming
stricter. Header field folding is a big issue too. I suspect that many
implementation do not consider that a request might contain two Host
header fields, simply because this is not supposed to be possible nor to
make sense at all. Similarly, "Connection: content-length" or equivalent
border-line things are not the problem of the implementation, but of the
spec. The spec has grown to a huge size because we tried to address that
many issues. But still you cannot document all corner cases because they
are invented every day and implementations cannot guess them all because
it's not their job.

So my point precisely is to try to enforce a stronger typing of exchanged
data to avoid a number of these issues as much as possible. For instance,
by using an integer to represent a date, you cannot send "29 Feb 2013",
and you don't need implementations to verify that this date makes any sense.

Received on Wednesday, 1 August 2012 05:43:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:05 UTC