W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: Misc Comments on Layering layering work and sections 1-5.

From: Jeff Pinner <jpinner@twitter.com>
Date: Mon, 8 Jul 2013 10:51:40 -0700
Message-ID: <CA+pLO_h08K7GzwUtc-c0La0RJp8U5ZovZPsBtzR0qeGcPnQ25A@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Mike Belshe <mike@belshe.com>, Michael Sweet <msweet@apple.com>, Amos Jeffries <squid3@treenet.co.nz>, httpbis mailing list <ietf-http-wg@w3.org>
Mike, thanks for looking over the draft. These suggestions mirror a few of
my own and seem mostly editorial.

I think the best way to address these at this point, and feel free to
disagree, is to merge streaming into master and release draft-04 for
implementation, then open these as new issues against draft-04.

On Fri, Jul 5, 2013 at 12:00 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> 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 Monday, 8 July 2013 17:52:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC