Re: HTTP/2.0 Magic

[Martin Thomson <[e-mail]>]

We almost certainly don't need to indicate the protocol version in this magic.

On 18 February 2013 22:57, Willy Tarreau <[e-mail]> wrote:
> I'm only seeing two valid reasons for prepending something :
>   1) if the frame encoding is compact enough to use all bits and make
>      an HTTP/1 response look like a possibly valid frame which the
>      client must parse, we'd prefer to avoid this useless work ;
>   2) if the frame can be tailored to look like an HTTP/1 response,
>      we'd prefer to avoid the possibility that this is triggered from
>      the client.

I think that an 8 byte frame header is small enough that it is
conceivable that it would be ignored, leading to the possibility that
the frame *body* could be made to look like an HTTP/1.x something.

> So maybe something looking like an HTTP/1 error may be useful then
> (eg: "HTTP/1.0 505 V2ONLY CRLF CRLF").

What we have suggest to me that it be *like* an HTTP/1.x response, but
be clearly NOT valid.  Making the response a valid HTTP/1.1 header is
only more likely to be passed as valid.  The goal is to die horribly
in as many clients and intermediaries as possible.

So, in the interest of concreteness, and in the spirit of Roy's suggestions:
  client-magic = %x73.6c.6f.77 CRLF CRLF
  server-magic = %x53.50.44.59 CRLF CRLF

Making sure to enforce case-sensitivity.  Then require either peer to
sever the connection if it sees anything else.

Note that this is followed immediately by a settings frame, which is
at least another 8 bytes.