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

Re: HTTP/2.0 Magic

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 1 Feb 2013 16:09:12 +0900
Message-ID: <CABkgnnVgbJmff-cj5-=1595BbrtV84MwMsKBj9J9R1+h0nvo7A@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
One more thing before I forget:

I know that it is tempting to come up with a vaguely funny or "clever"
magic.  (Someone suggested 0xdeadbeef, which does meet the criteria)
However, what would be really good is if there were input in the form:

"4 bytes is not sufficient, client/server X ignores N garbage bytes
before deciding that a connection is thrown away";
"X ignores lots of bytes, but sending Connection:close in the upgrade
might work";
"um, that's valid UTF-8, some implementations parse that".

On 1 February 2013 10:24, Martin Thomson <martin.thomson@gmail.com> 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.
Received on Friday, 1 February 2013 07:09:39 UTC

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