Re: HTTP/2.0 Magic

On Jan 31, 2013, at 5:24 PM, 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.

Umm, sending high bit characters is far more likely to be ignored
or trigger parsing bugs than simple ascii.

The best way to a quick and safe end (actually tested in
practice 10 years ago) is to send something that looks like a method
and ends with CRLF.  Hence, waka sends a 64bit value

   wakaVV<CRLF>

where the first V is the version being sent and the second V is the
highest version accepted.  Both are a variant of base64 that starts
at 0, so the beginning of each message is

  77 61 6b 61 30 30 0d 0a

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

Don't worry about it.  The group is working on HTTP/2, not some
private hack, and it simply doesn't matter how many bugs you
trigger in broken intermediaries.  They will fix themselves.

....Roy

Received on Friday, 1 February 2013 07:17:51 UTC