- 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" <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