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

Re: HTTP/2.0 Magic

From: Dr Robert Mattson <robert@mattson.com.au>
Date: Fri, 1 Feb 2013 14:47:19 +1100
Message-Id: <6BFC2030-75E3-4ABE-8B47-13972DD577BA@mattson.com.au>
Cc: "Adrien W. de Croy" <adrien@qbik.com>, Roberto Peon <grmocg@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
To: Eliot Lear <lear@cisco.com>
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.
Received on Friday, 1 February 2013 03:47:51 UTC

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