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

In message <CABP7RbeUeFo00+J7dknuqV0sgS=6Nh-BnUjuyRenAvg1wb+EEw@mail.gmail.com>, James M Snell writes:

>I'd very much like to see such changes made within 2.0, but I'm
>afraid that I may be in the minority.

In message <20120801054322.GA14213@1wt.eu>, Willy Tarreau writes:

>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.

+1

HTTP/1.1 was specified to try to salvage every single request, no matter
how malformed, because "malicious" was not in the vocabulary back then.

HTTP/2.0 should formally recognize the existence of net.crime and
make it easier to defend yourself against net.crime.

My preferred solution is:

	HTTP/2.0 is defined as a semantic subset of HTTP/1.1, leaving
	as much of the trouble behind as possible.

	If a client cannot send a given request as HTTP/2.0, it SHALL
	fall back to HTTP/1.1 instead.

For web-browsing all user-agent initiated requests are trivial GETs,
which naturally fit in HTTP/2.0.

The transactions which could possibly run foul of HTTP/2.0's
strictness are all the result of stuff the server sends to the
client (forms, javascript etc).  If server-owners what the benefit
of HTTP/2.0, they will and can fix their stuff.

For any API use of HTTP, either the API is defined so it works with
HTTP/2.0 or the API must stay in HTTP/1.1 until suitably upgraded,
at the discretion of the entity which offers the API.

Since HTTP/2.0 is a semantic subset of HTTP/1.1, translation from
2.0 request to 1.1 is a trivial 1:1 mapping.  If the response cannot
be mapped back, the transaction should be assumed failed, and the
translating intermediary should return "50x Use HTTP/1.1 instead"

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Wednesday, 1 August 2012 07:47:23 UTC