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

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.

Regards,
Willy

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