W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

WGLC - Editorial feedback /questions on p1

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 30 Oct 2012 14:36:46 +1100
Message-Id: <DAED760B-AC6A-44A6-816C-59EEEF705E4E@mnot.net>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
To: Roy Fielding <fielding@gbiv.com>, "Julian F. Reschke" <julian.reschke@gmx.de>
After a closer review, some editorial suggestions, with a few questions mixed in. Some may turn into design issues, depending on how incorporation/discussion goes.

* Section titles - I wonder if we should call section two "HTTP Architecture" instead of "Architecture", and then prefix 3, 4, 5, and 6 with "HTTP/1.1", e.g., "3. HTTP/1.1 Message Format". Just a suggestion.

* 1. Introduction -- "However since multiple clients might act in parallel..." Should also mention that other interfaces to the underlying data can change its state.

* 1. Introduction -- three paragraphs, starting with "HTTP is a generic interface protocol..." would fit better in Section 2 Architecture.

* 1. Introduction -- "One consequence of HTTP flexibility..." --> "...HTTP's flexibility..."

* 2.1 Client/Server Messaging -- "..refer to whichever component sent a given message..." --> "...refer to any component that sends a given message..."   (aligns with similar text nearby)

* 2.5 Conformance and Error Handling -- "...recipient MUST be able to parse any value that would match the ABNF rules..."  yet 3.2.2 only make parsing obs-fold a SHOULD. Which is it?

* 2.6 Protocol Versioning - should reference the 505 status code in P2

* 2.7.1 http URI Scheme - "... because the name delegation process depends on TCP for establishing authority." --> "... because the name delegation process uses the TCP port number (among other things) to establish identity."

* 2.7.2 https URI scheme - same as above

* 2.7.1 http URI Scheme, last para - '...when transmitting an "http" URI in a message.' --> '...when transmitting an "http" URI in a request-target.'  

* 2.7.1 Stick with "an HTTP" or "a HTTP".

* 2.7.2 "... MUST NOT be reused for shared caching." This requirement needs to be explicitly added to p6, and referenced from here.

* 3 Message format -- "Recipients MUST parse an HTTP message as a sequence of octets in an encoding that is a superset of US-ASCII." --> "... US-ASCII or a superset of it."

* 3.1 Request Line -- There isn't a requirement for recipients of messages with whitespace between the start-line and the first header field. Should there be?

* 3.1.1 "A server MUST be able to parse any received message that begins with a request-line and matches the ABNF rule for HTTP-message."  This repeats the ABNF requirement in the conformance section; should be removed.

* 3.1.1 "...at a minimum, request-line lengths of up to 8000 octets."  Remove "up to"; redundant.

* 3.1.1 Request Line and 3.1.2 Status line -- RFC2616 specifically allowed multiple SP and HT in these constructs --

>    Clients SHOULD be tolerant in parsing the Status-Line and servers
>    tolerant when parsing the Request-Line. In particular, they SHOULD
>    accept any amount of SP or HT characters between fields, even though
>    only a single SP is required.   (19.3 Tolerant Applications)

Yet this text seems to have been lost. Given that HT isn't even in the BNF, it should still be somewhere.

* 3.2 Header Fields -- talks about there being no limit on the number of header fields in a message. This should reference 3.2.3, which indicates how respond when they're too long (or that content should be moved here). Should also reference rfc6585 for 431 Request Header Fields too Large. 

* 3.2 Header Fields -- The advice regarding Set-Cookie2 in the note at the end appears to endorse that header; however, it has been obsoleted. This text should be removed.

* 3.2.1. Whitespace -- uses "produce" instead of "generate" (as per the language in the conformance section).

* 3.2.2. Field Parsing -- uses "produce" instead of "generate" (as per the language in the conformance section).

* 3.2.2. Field Parsing "A proxy MUST remove any such whitespace..."  Should this be "intermediary"?

* 3.2.4 Field value components -- there are two instances of "Senders SHOULD NOT escape octets..."  these requirements need to be scoped to senders *that generate* the indicated components; those merely forwarding messages shouldn't be required to fix them up.

* 3.3.1 Transfer-Coding -- "The "chunked transfer-coding (Section 4.1) MUST be implemented..."  This paragraph specifies that "chunked" MUST be last two times; once is enough.

* 3.3.1 Transfer-Coding -- "If more than one Transfer-Encoding header field is present in a message, the multiple field-value MUST be combined into one field-value, according to the algorithm defined in Section 3.2, before determining the message body length."  This doesn't make a lot of sense -- what's the motivation?

* 3.3.1 Transfer-Coding -- "A server that receives a request message with a transfer-coding it does not understand SHOULD respond with 501..."  There isn't a corresponding requirement for when 'chunked' is not the final coding, or occurs more than once. Should there be?

* 3.3.3 Message Body Length -- "The provided Content-Length header MUST be removed, prior to forwarding the message..." --> "The provided Content-Length header MUST be removed by senders prior to forwarding the message..." (make requirement target explicit)

* 3.4 Handling Incomplete Messages -- "Request messages that are prematurely terminated, possibly due to a cancelled connection or a server-imposed time-out exception, MUST result in closure of connection..."  It's not clear what target this requirement applies to -- clients? It should be explicit.

* 3.4 Handling Incomplete Messages -- "... cannot be assumed to convey the full semantics of the response and MUST be treated as an error."   Specify target '... by recipients."

* 3.4 Handling Incomplete Messages -- "A user agent MUST NOT render..." --> "A user agent MUST NOT consider..."

* 3.5 Message Parsing Robustness -- "When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed above, the server must respond with an HTTP/1.1 400 (Bad Request) response."  This makes several existing implementations non-conformant (because they silently digest whitespace in those empty lines). See also the issue above about Tolerant Applications and SP/HT in the top-line.

* 3.5 Message Parsing Robustness -- "If terminating the request message body with a line-ending is desired, then the client MUST include the terminating CRLF octets as part of the message body length."   I think the correct target for the requirement here is user agent, not client. 

* 5.6, 5.7 and 5.8 -- it seems like 5.6 Message forwarding should really be a top-level section (perhaps with the word "intermediary" in it), with the current 5.7 and 5.8 under it. At the very least, 5.7 should be 5.6.1 and 5.8 should be 5.6.2.

* 5.6 Message Forwarding -- "...exclude fields that are only intended for the incoming connection." --> "...exclude fields that are only scoped to the incoming connection."

* 5.6 Message Routing -- 2616 listed several headers that are always hop-by-hop, whether or not they show up in Connection; e.g., Keep-Alive, Upgrade, TE.  This spec AFAICT does not enumerate them, which may cause interop problems. Was that intentional?

* 5.8 Message Transforming --> Message Transformation

* 5.9 Associating a Response to a Request -- "A client that uses persistent connections and sends more than one request per connection..." --> "A client that has more than one outstanding request on a connection..."

* 6.1 Connection cautions against using existing header field names as connection tokens, and we register 'connection', but there isn't a requirement (or encouragement) to register connection tokens in the header field registry. Should there be?

Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 30 October 2012 03:37:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:07 UTC