Routing Data's relationship to headers

[mnot]

Right now, routing data (in particular, :scheme, :host and :path) appear as headers along with the rest.

This means that the recipient needs to parse through the header collection to find them -- potentially at the end.

Different ways of addressing this have been proposed; e.g., requiring them to be at the top of the header block, or serialising them in different fields.

[martinthomson]

Alexey will provide proposed text. This will probably include moving S6.2 (HTTP Header Fields and HTTP/2.0 Headers) out of security considerations to the relevant section (S4.2).

[aamelnikov]

Made the change change proposed above. If the WG wants a fixed order of ":"-header fields, this should be another change.

[jpinner]

This request seems to be based on the "stream" compression of the headers, it is unclear how this might fit in with the new header compression scheme. I'd like to see that land before we place requirements on header ordering.

[mnot]

Discussed in Hamburg; need more data - input from intermediary / proxy vendors as to how desirable this is; the relative expense of reading / transmitting compressed vs. uncompressed Host header; whether more headers than Host are necessary.

Requiring that certain headers be available in certain ways from the compressor seems to increase complexity considerably, and likely isn't a good road, as it's a tradeoff of space (on the wire, in buffers, etc.), but not necessarily an assurance of saving time.

[mnot]

Revisited in Seattle; adding ordering the current compression scheme would increase complexity for marginal benefit. It is currently implementable.