Re: HTTP/2.0 Magic

This will destroy transparent backward-compatability with older HTTP versions.
Any reduction in page retrieval time could be dwarfed by such awkward interaction.
HTTP-MPLEX proposed the use of TXT records in the DNS to use a /proc/cpu:flags like mechanism to accompany the uri/ip conversion request. Highly scalable and only delays the request by the time it takes to send and receive slightly larger udp packets.

Sent on a mobile device, typos expected.

On 01/02/2013, at 2:11 PM, Eliot Lear <lear@cisco.com> wrote:

> The alternative is to append something for version info.
> 
> On 2/1/13 12:09 PM, Adrien W. de Croy       wrote:
>>  
>>  
>> ------ 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.
>