Re: HTTP/2.0 Magic

Hi Martin,

On Fri, Feb 01, 2013 at 10:24:30AM +0900, Martin Thomson wrote:
> The conclusion that we reached in the interim was that no matter how
> HTTP/2.0 was started, there would be some magic that started the
> session.
> 
> The requirements for that magic is that it is designed to cause a
> reasonable proportion of HTTP/1.1 implementations to fail, preferably
> to close the connection.
> 
> This magic also provides a high degree of confidence that the protocol
> you are talking is actually HTTP/2.0 and not something else.
> 
> As far as I am aware, the actual sequence does not matter much, though
> having the first bit set ensures that this isn't valid HTTP/1.1.
> 
> I generated a random number.  In this case, a 32-bit value.  Happily,
> the high bit is set:
> 
>   e1c54784
> 
> As we discussed, this would be sent at the start of every session and
> be followed immediately by a SETTINGS frame.  Both client and server
> send this sequence.
> 
> The concern here is that some implementations will swallow this and
> proceed anyway.  Those implementations wont fail as a result of seeing
> this.  It may be the case that for those implementations no amount of
> magic is sufficient as the tests that lead to websockets masking
> revealed.

I'm really scared that we're doing again the same mistakes as websocket
initially did and that we go through the exact same process of stacking
idiocies on top of each other until everyone is more or less happy with
the result. We should be very careful here because it started like this.

HTTP is a well defined protocol and it supports an upgrade mechanism, I
think it should be better to reuse this standardized and documented
mechanism than guessing what will happen with some random magic and then
have many people complain about broken devices which transparently pass
the signature, then have some security folks show to the world the high
risk it represents and then have everyone suggest how to cripple the
design so that caches are not at risk.

BTW if we're really going down that road, Roy is right that the prefix
should look like a method so that at least most devices take this for
a minimalistic HTTP/0.9 request and don't try to parse more than what
they get.

Willy

Received on Friday, 1 February 2013 07:35:34 UTC