- From: Greg Wilkins <gregw@intalio.com>
- Date: Mon, 2 Jun 2014 11:19:00 +0200
- To: Roberto Peon <grmocg@gmail.com>
- Cc: K.Morgan@iaea.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, jgreene@redhat.com, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAH_y2NFZB=n0=rwE5-=3RmptuwnYfBajzJJRc8v1BfMG26R+rw@mail.gmail.com>
On 1 June 2014 02:21, Roberto Peon <grmocg@gmail.com> wrote: > > > Poul's proposal to put routing info at the front pre-supposes that all > proxies use the same information for routing.This is often not the case. > It is true that some proxies will want to look at arbitrary request meta data - including cookies- to make their routing decisions. Such proxies are committed to full decoding. However, there is also a large class of proxy that will want to look at only the basic information. So perhaps it is time that we restricted the transport meta data to only carry transport meta data, and to move the extra meta-data to a secondary header set? Ie if we extended Poul's proposal so that all headers defined by the http2 specification for the use of transport, and only those headers, are in an initial header set. A subsequent header set can then contain all of the additional headers that an application/client/server may add. Proxies that want to route only on the core http defined fields, can then just decode the first header set. Proxies that wish to route based on additional headers (including cookies), would have to decode both sets. I've always found it bizarre that HTTP design often results in allowing applications to set headers like Transfer-Encoding! This has been discussed before, I'll point out. > My limited experience of the IETF process indicates that WG such as this often do have to re discuss design decisions made long ago. This process tends to iterate until either the spec and associated document because clear enough to explain the main design decisions, OR more likely that the re-discussions appear to be mostly provoked from the same set of chronic malcontents who wont accept they have not made their case. For my own part, I have found the recent discussions very worthwhile and I very much appreciate those who have taken the time to (re)explain why many of the decisions have been made. While I am critical of parts of the spec, I am impressed at the depth of the reasoned explanations for almost all of them. So thanks for staying engaged and spending the time to explain. cheers -- Greg Wilkins <gregw@intalio.com> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Received on Monday, 2 June 2014 09:19:29 UTC