Re: HTTP/2.0 Magic

[Willy Tarreau <[e-mail]>]

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 <[e-mail]> 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.

> * 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.
Willy