- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 19 Feb 2013 17:24:02 +1100
- To: Willy Tarreau <w@1wt.eu>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 19/02/2013, at 5:21 PM, Willy Tarreau <w@1wt.eu> 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 <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 > 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/
Received on Tuesday, 19 February 2013 06:24:30 UTC