- From: Michael Sweet <msweet@apple.com>
- Date: Fri, 05 Jul 2013 14:31:48 -0400
- To: Mike Belshe <mike@belshe.com>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, httpbis mailing list <ietf-http-wg@w3.org>
- Message-id: <489C63A2-FFCE-440E-A639-5FF1035D64A1@apple.com>
Mike/Amos, On 2013-07-05, at 1:19 PM, Mike Belshe <mike@belshe.com> wrote: > ... > Since this is being built as an upgrade on HTTP/1 and many implementers will have an HTTP/1 terminology background it would seem easier to use that terminology for these things. The suggested "START_STREAM" was once called "request headers" or "reply headers" depending on direction. It is now combined into one frame type for both directions so perhapse dropping the initial word and just calling it a HEADERS will be more familiar to implementers, yes? > > I'm looking for a name that indicates "beginning" or "start". HTTP/1 doesn't have framing, of course, but does offer "Section 5. Request". It's a logical start point -- make a request. Something that's bugged me a little is that the context/directionality of the HEADERS frame type - you make certain assumptions that if you receive a HEADERS frame then you work with one header table and if you send a HEADERS frame then you work with a different table. Whether you are receiving or sending request or response headers is implied by your role in a connection, and that is state you need to maintain and use in your implementation and clearly document, particularly in any generic client/server code that is shared between the two sides. 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 need for two DATA frame types - DATA always follows headers and just depends on direction and the request/response type...) _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Friday, 5 July 2013 18:32:23 UTC