Re: HTTP/2.0 Magic

[Mark Nottingham <[e-mail]>]

On 19/02/2013, at 5:21 PM, Willy Tarreau <[e-mail]> 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 <[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.

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


Yes.

Cheers,


--
Mark Nottingham   http://www.mnot.net/