sgtm. On Mon, Jul 8, 2013 at 10:51 AM, Jeff Pinner <jpinner@twitter.com> wrote: > 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 18:38:33 UTC