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

Re: HTTP/2.0 Magic

From: Willy Tarreau <w@1wt.eu>
Date: Tue, 19 Feb 2013 07:21:00 +0100
To: Mark Nottingham <mnot@mnot.net>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20130219062100.GA26186@1wt.eu>
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

> * 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". It causes two major pains :
  - adds a round trip
  - is not SYN cookies-friendly, making it much harder to protect many
    web sites

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

Just my two cents.
Received on Tuesday, 19 February 2013 06:21:41 UTC

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