- From: Michael Sweet <msweet@apple.com>
- Date: Tue, 09 Jul 2013 13:12:19 -0400
- To: "ietf-http-wg@w3.org list" <ietf-http-wg@w3.org>
- Message-id: <3072E3B4-63B4-4DFB-AFD8-08EE6407C6FB@apple.com>
All, A couple quick comments on draft-ietf-httpbis-http2-04... In section 8.1.1 Examples I see the following: All HTTP Requests that include a body SHOULD include the "content- length" header field. If a server receives a request where the sum of the DATA frame payload lengths does not equal the value of the "content-length" header field, the server MUST return a 400 (Bad Request) error. I am uncomfortable with this wording primarily because a lot of POST usage consists of streamed content - my particular interest is obviously printing, but any streamed content will necessarily not be able to provide a content-length header field. So instead I would suggest the following two paragraphs instead: All HTTP requests that include a body of known length MUST include the "content-length" header field. If a server receives a request where the sum of the DATA frame payload lengths does not equal the value of the "content-length" header field, the server MUST return a 400 (Bad Request) error. All HTTP requests that include a body of unknown length MUST NOT include the "content-length" header field. Servers MUST support receiving requests without a "content-length" header field and MUST return a 413 (Request Entity Too Large) error if the body is too large to process. This clearly defines how clients stream content to servers and defines the error handling required. And it makes the conformance requirements less squishy... My other comment is that I don't see any discussion of the Expect header, nor do I see a issue on Github... But this is something that gets used extensively in printing to avoid sending gigabytes of print data to a printer that needs authentication for certain operations... Perhaps something to add to section 8.1.1, e.g.: Use of Expect with 100 (Continue) response: POST /ipp/print HTTP/1.1 HEADERS Host; printer.example.org ==> - END_STREAM Content-Type: application/ipp + END_HEADERS Transfer-Encoding: chunked :method = post Expect: 100-continue :scheme = ipp :host = printer.example.org :path = /ipp/print content-type = application/ipp expect = 100-continue HTTP/1.1 100 Continue ==> HEADERS - END_STREAM + END_HEADERS :status = 100 {binary data from client} ==> DATA + END_STREAM {binary data} HTTP/1.1 200 OK ==> HEADERS Content-Type: application/ipp - END_STREAM Transfer-Encoding: chunked + END_HEADERS :status = 200 {binary data from server} content-type = application/ipp DATA + END_STREAM {binary data} Failed response needing authentication: POST /ipp/print HTTP/1.1 HEADERS Host; printer.example.org ==> - END_STREAM Content-Type: application/ipp + END_HEADERS Transfer-Encoding: chunked :method = post Expect: 100-continue :scheme = ipp :host = printer.example.org :path = /ipp/print content-type = application/ipp expect = 100-continue HTTP/1.1 401 Unauthorized ==> HEADERS Content-Type: text/html - END_STREAM Content-Length: 123 + END_HEADERS WWW-Authenticate: Basic ... :status = 401 www-authenticate = Basic ... {HTML error message from server} Then we'd also need a clarification in section 8.1.3 to allow a single HEADERS response frame with :status = 100. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Tuesday, 9 July 2013 17:12:46 UTC