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

Re: HTTP/2.0 Magic

From: Adrien W. de Croy <adrien@qbik.com>
Date: Fri, 01 Feb 2013 03:09:34 +0000
To: "Eliot Lear" <lear@cisco.com>, "Roberto Peon" <grmocg@gmail.com>
Cc: "Martin Thomson" <martin.thomson@gmail.com>, "HTTP Working Group" <ietf-http-wg@w3.org>
Message-Id: <emba5e5b34-4cce-4287-b8da-fb1680106e92@bombed>

------ Original Message ------
From: "Eliot Lear" <lear@cisco.com>
To: "Roberto Peon" <grmocg@gmail.com>
Cc: "Martin Thomson" <martin.thomson@gmail.com>; "HTTP Working Group" 
Sent: 1/02/2013 4:04:49 p.m.
Subject: Re: HTTP/2.0 Magic
>Separately we will also need a version identifier.  This field can ALSO 
>server as a version identifier.  We just rev/change the magic on a new 
I wouldn't do that.

network sniffers will get coded to the magic number.  They'd need to be 
recoded to even recognise the new version with a different magic number 
as being still HTTP


>On 2/1/13 11:35 AM, Roberto Peon wrote:
>>How about: d3 d0 c4 d9? (as an hommage).
>>Honestly, though, anything which spells out something easy to remember 
>>in 7-bit ascii when the high-bits are all xor'd would be nice :)
>>On Thu, Jan 31, 2013 at 5:24 PM, 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
>>>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 
>>>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, 
>>>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 
>>>this.  It may be the case that for those implementations no amount of
>>>magic is sufficient as the tests that lead to websockets masking
Received on Friday, 1 February 2013 03:10:25 UTC

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