Re: HTTP/2.0 Magic

------ Original Message ------
From: "Eliot Lear" <lear@cisco.com>
To: "Roberto Peon" <grmocg@gmail.com>
Cc: "Martin Thomson" <martin.thomson@gmail.com>; "HTTP Working Group" 
<ietf-http-wg@w3.org>
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 
>version.
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

Adrien

>
>
>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 :)
>>
>>-=R
>>
>>
>>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
>>>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 03:10:25 UTC