HTTP/2.0 Magic

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.

Received on Friday, 1 February 2013 01:24:57 UTC