W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: HTTP/2.0 Magic

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 31 Jan 2013 23:17:26 -0800
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <8F582448-A298-4BC0-A843-ACA4354AB109@gbiv.com>
To: Martin Thomson <martin.thomson@gmail.com>
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


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.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC