- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 19 Feb 2013 12:02:11 -0800
- To: Willy Tarreau <w@1wt.eu>
- Cc: Mark Nottingham <mnot@mnot.net>, "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
We almost certainly don't need to indicate the protocol version in this magic. On 18 February 2013 22:57, Willy Tarreau <w@1wt.eu> 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.
Received on Tuesday, 19 February 2013 20:02:56 UTC