- From: James M Snell <jasnell@gmail.com>
- Date: Thu, 31 Jan 2013 23:09:42 -0800
- To: Ted Hardie <ted.ietf@gmail.com>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CABP7RbcEjjtD3eaeZuQ7+KswXHd3FJMKiYMJR2sK51YD3J2epA@mail.gmail.com>
One proposal on this particular topic... We can combine the :scheme, :method, :host and :path header fields into a single :req Header with a compact binary encoding and require that this single header always appear first in request header blocks. +------------------------------+ |S|len(method)|method|len(host)| +-+-------+----+---------+-----+ | host | len(path) | path | +------------------------------+ S = Single bit, when set, scheme = https, when not set, scheme = http len(method) = 7 bit length of method name method = name of method len(host) = uvarint(host) host = host len(path) = uvarint(path) path = path Examples: GET request for http://example.net/foo would be: [03,G,E,T,0B,e,x,a,m,p,l,e,.,c,o,m,04,/,f,o,o] POST request for https://example.net/foo would be: [84,P,O,S,T,0B,e,x,a,m,p,l,e,.,c,o,m,04,/,f,o,o] Unregistered method 'FOO' request for https://example.net/foo would be: [83,F,O,O,0B,e,x,a,m,p,l,e,.,c,o,m,04,/,f,o,o] If the client chooses not to send a host (because it's not needed or whatnot) they simply set len(host) to 0... [03,G,E,T,00,04,/,f,o,o] If we do end up going with delta encoding for compression, we can require that the :req Header always be passed using the eref operation (ephemeral reference, meaning that the header is never stored in the compression state). No huffman-coding would be applied to the header, making it very quick and cheap to process. Thoughts? - James On Thu, Jan 31, 2013 at 8:04 AM, Ted Hardie <ted.ietf@gmail.com> wrote: > On Thu, Jan 31, 2013 at 5:15 AM, Roy T. Fielding about this > > >> We had no idea how early we were in the popularity curve of HTTP or > >> how dominant it would become, but it was clear even then that the > >> protocol would be very, very common on the network. In retrospect, it > >> is clear that we shouldn't have looked at the current installed > >> base--we should have looked at what we expected eventual use would be. > >> That makes "the earlier the better" clear. > > > > I think your memory is a bit hazy there ... HTTP passed all > > application protocols other than email in 1995, and by that > > time (Mar 1996) was roughly double email traffic, IIRC (this was > > before email-based spam became common). That's why the WG > > meeting contained a lot of people who had nothing to do > > with developing the Web protocols---there was panic in the air. > > > > I think we can both agree it only got more popular from there. It may > well have surpassed email by that discussion, but the hockey stick had > a lot of run to go. > > > I find it amusing that you think we could have proceeded in any > > other way without relegating the IETF work to the garbage bin. > > > > It would have taken agreement from a lot of people, but the web > community of the time could have decided then to rev the major > protocol version for that change. That suggestion was made. The IETF > could not have mandated that. The IETF *never* gets to dictate > protocol changes--it didn't have police then and it doesn't now, but > saying that the buy-in for that change didn't happen doesn't equate to > saying it could not. > > regards, > > Ted > >> For HTTP 2.0, where we can make non-backward compatible changes, I > >> personally think the right thing to do is to drop the Host: header > >> (that version shift is what we were waiting for 17 years ago, after > >> all). If there are things folks are getting from side-effects of the > >> Host header (e.g. proxy targeting), we put them into the bin of > >> potential requirements for HTTP 2.0 *and create mechanisms to meet > >> those needs*. > >> > >> I think Adrien's proposal for extensions to the host header makes > >> clear that the need isn't perfectly met by the host header in any > >> case, so mapping out the real aim and meeting that seems like the best > >> notion to me. > > > > Oddly enough, waka separates the scheme+host routing information from > > the rest of the URI because that works better with multi-argument > > methods and message-based encryption. *shrug* > > > > ....Roy > > > >
Received on Friday, 1 February 2013 07:10:29 UTC