- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 5 Jul 2013 12:00:33 -0700
- To: Mike Belshe <mike@belshe.com>
- Cc: Michael Sweet <msweet@apple.com>, Amos Jeffries <squid3@treenet.co.nz>, httpbis mailing list <ietf-http-wg@w3.org>
On 5 July 2013 11:48, Mike Belshe <mike@belshe.com> wrote: >> What if instead we had two frame types: REQUEST_HEADERS and >> RESPONSE_HEADERS? Both would carry headers like the current HEADERS frame >> type, but the type of headers would be clearly defined by the frame type and >> perhaps be easier/less error prone to understand and implement. I don't see a real advantage to this. An endpoint knows its role. It can perform a lookup: initial_headers_table[myrole]. A more advanced approach might be to use a setting to describe which initial headers table to use. But I think that we've concluded that this is better negotiated during the TLS handshake (that is, negotiate a new protocol). > I realize > HTTP is request/response (push excluded), and we're not building a generic > framing layer. Push is really request/response too :) The request is explicit too, it just doesn't originate at the client.
Received on Friday, 5 July 2013 19:01:01 UTC