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

Re: HTTP/2.0 Magic

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 19 Feb 2013 17:24:02 +1100
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <5C517A54-2C3D-40C3-8C87-C1A362F6CC70@mnot.net>
To: Willy Tarreau <w@1wt.eu>

On 19/02/2013, at 5:21 PM, Willy Tarreau <w@1wt.eu> wrote:

> On Tue, Feb 19, 2013 at 04:21:01PM +1100, Mark Nottingham wrote:
>> [ Now: https://github.com/http2/http2-spec/issues/25 ]
>> On 01/02/2013, at 6:17 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>>> Umm, sending high bit characters is far more likely to be ignored
>>> or trigger parsing bugs than simple ascii.
>>> The best way to a quick and safe end (actually tested in
>>> practice 10 years ago) is to send something that looks like a method
>>> and ends with CRLF.  Hence, waka sends a 64bit value
>>>  wakaVV<CRLF>
>>> where the first V is the version being sent and the second V is the
>>> highest version accepted.  Both are a variant of base64 that starts
>>> at 0, so the beginning of each message is
>>> 77 61 6b 61 30 30 0d 0a
>> I like the general approach. A few questions:
>> * Should it end with CRLFCRLF? Seems to me this _might_ fast fail on a few
>> more implementations.
> Indeed it should. For example I have an old crappy test server which waits
> for the empty line whatever the request line looks like. Similarly, mini_httpd
> did this (and I've seen it used in several embedded devices).
> However, I remember that when the same approach was proposed on hybi, one
> of the concerns that was raised was that some servers will happily return
> a valid response and may corrupt intermediary caches. I remember that about
> all intermediary implementations authors explained that no cache will ignore
> the method in the request, but still that was a concern that plagued the
> design.

I'm not convinced it's a concern.

>> * Is the magic identifying the underlying framing layer in use (what we're
>> now calling HTTP/2, but I suspect we might want to start calling it something
>> else), the profile in use over it, or both? My sense is that both is perhaps
>> best.
> I personally don't understand what it's about :-/
>> * Is the magic sent by a client upon connect, by a server upon connect, or both?
> We should absolutely not have a "banner protocol".

Definitely not; question is whether the server prepends something to the start of the framing layer.

> So the client must speak first. If we decide that it's desirable that
> the server responds, we must use a different pattern to avoid false
> positives on echo servers or those which would return a message such
> as "FOO CRLF unknown method".



Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 19 February 2013 06:24:30 UTC

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