Re: WGLC: p1 MUSTs

Now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/484>.


On 01/05/2013, at 4:54 AM, Alex Rousskov <rousskov@measurement-factory.com> wrote:

> Hello,
> 
>    Summary: The specs have improved considerably since 2012. Thank you
> for not giving up on them despite HTTP/2.0 excitement!
> 
> Due to the lack of time, I have to focus on MUST-level requirements
> only. These comments are based on the "latest" snapshot dated Mon 29 Apr
> 2013 03:13:05 PM MDT at
> https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p1-messaging.html
> 
> I hope these comments can be addressed by editors alone, but I apologize
> in advance if some are found too controversial and should have been sent
> separately.
> 
> 
>> A sender MUST NOT generate protocol elements that do not match the
>> grammar defined by the ABNF rules for those protocol elements that
>> are applicable to the sender's role.
> 
> The "for those protocol elements..." part should be dropped IMO. A
> sender MUST NOT generate invalid protocol elements even if they are not
> applicable to the sender's role. Note that we are talking about
> _generation_ and not forwarding here.
> 
> 
>> If a received protocol element is processed, the recipient MUST be
>> able to parse any value that would match the ABNF rules
> 
> "processed" seems too broad because simply buffering a header may be
> called "processing". "Interpreted" may be better. Or did I miss the
> definition of "process" that clarifies this?
> 
> 
>> If a received protocol element is processed, the recipient MUST be
>> able to parse any value that would match the ABNF rules for that
>> protocol element, excluding only those rules not applicable to the
>> recipient's role.
> 
> The "excluding only those rules not applicable..." part seems to
> contradict the "processed" verb. Why would a recipient want to process
> something inapplicable? Perhaps this is related to the "process" versus
> "interpreted" issue mentioned above.
> 
> 
>> the recipient MUST be
>> able to parse any value that would match the ABNF rules for that
>> protocol element, excluding only those rules not applicable to the
>> recipient's role.
> 
> Please rephrase to avoid double negation in "excluding not applicable".
> For example: "the recipient MUST be able to parse any value matching the
> corresponding ABNF protocol element rules applicable to the recipient's
> role"
> 
> 
>> Senders MUST exclude the userinfo subcomponent (and its "@"
>> delimiter) when an "http" URI is transmitted within a message as a
>> request target or header field value.
> 
> The above MUST should not apply to proxies, right? Policing forwarded
> URLs will break applications and policing forwarded extension header
> fields is not possible at all and would violate the "MUST forward" rule.
> How about "senders MUST NOT generate"?
> 
> 
>> A server MUST be prepared to receive URIs of unbounded length
> 
> This MUST may be demoted to "ought" because "be prepared" is too vague
> (but see below for a related missing MUST).
> 
> 
>> A server MUST be prepared to receive URIs of unbounded length and
>> respond with the 414
> 
> Please insert a second MUST after "and": "and MUST respond".
> 
> 
>> Multiple header fields with the same field name can be combined into
>> one "field-name: field-value" pair
> 
> Should this be a MAY as in "The recipient MAY combine multiple ...". As
> worded now, it is not clear whether a proxy is allowed to combine
> headers when forwarding them. Note that this affects extension and other
> headers that a proxy may not understand (but may still want to combine
> if allowed to do so).
> 
> 
>> A server MUST be prepared to receive request header fields of
>> unbounded length and respond
> 
> Consider removing the above MUST but please add MUST after "and": A
> server ought to be prepared to receive ... and MUST respond ...
> See above for discussion of a similar MUST that applies to URIs of
> unbounded length.
> 
> 
>> A client MUST be prepared to receive response header fields of unbounded length.
> 
> Same here, except no new MUST is needed.
> 
> 
>> If chunked is applied to a payload body, the sender MUST NOT apply
>> chunked more than once
> 
> The precondition is bogus: If chunked is NOT [yet?] applied to a payload
> body, the sender still MUST NOT apply chunked more than once!
> 
> 
>> the sender MUST NOT apply chunked more than once
> 
> This needs to be rephrased to make it clear that proxies are not
> responsible for dechunking multiple chunked encodings to make the
> forwarded message comply with this MUST. For example, we could say: "the
> sender MUST NOT generate messages with multiple chunked encodings".
> 
> Please note that both the proposed "multiple chunked encodings" and the
> existing "more than once" wordings imply that foo,chunked,bar,chunked
> combination is also not allowed.
> 
> 
>> A server MUST send an empty trailer with the chunked transfer coding
>> unless at least one of the following is true:
> 
> This should be relaxed to "A server MUST generate ..." because a proxy,
> in general, does not know whether bullet #2 ("the trailer fields consist
> entirely of optional metadata...") is true. Even though chunking is a
> hop-by-hop mechanism, proxies ought to forward Trailers whenever
> possible, right?
> 
> 
>> a client MUST send only the absolute path and query components of the
>> target URI as the request-target
> 
>> To allow for transition to the absolute-form for all requests in some
>> future version of HTTP, HTTP/1.1 servers MUST accept the
>> absolute-form in requests
> 
> Should the first "MUST send" be relaxed to "MUST generate" so that the
> proxies do not block the apparently anticipated "transition to the
> absolute-form for all requests" by stripping URIs as they forward them?
> 
> 
>> In order to avoid request loops, a proxy that forwards requests to 
>> other proxies MUST be able to recognize and exclude all of its own
>> server names
> 
> Several intermingled issues here:
> 
> 1) The "other proxies" prerequisite is a red herring IMO. Any proxy
> should avoid request loops. If a proxy that is not configured to forward
> request to other proxies sends an "origin server" request to itself,
> such a request may still create a loop. I think the following would be
> better: "In order to avoid request loops, a proxy MUST ..."
> 
> 2) If we want the proxy to recognize and exclude, let's demand that
> instead of just demanding that the proxy is able to do that (but
> possibly does not do it): "a proxy ... MUST recognize and exclude ...".
> 
> 3) This MUST may benefit from some polishing to clarify what "exclude"
> means. I think it means "reject" in this context.
> 
> 4) The "recognize" part can be dropped because recognition is implied by
> the "exclude" requirement.
> 
> At the end, we may arrive at something like this:
> 
> "In order to avoid request loops, a proxy MUST reject requests for
> itself, including requests where the server address is formed using a
> proxy domain name, its aliases, local variations, or literal IP addresses."
> 
> 
>> A client that does not support persistent connections MUST send the
>> "close" connection option in every request message.
> 
> Including a CONNECT request message?
> 
> 
>> A client that pipelines requests MUST be prepared to retry those requests
> 
> MUST be prepared to retry but does not have to retry? Or MUST retry?
> 
> 
>> A client that pipelines requests MUST be prepared to retry those
>> requests if the connection closes before it receives all of the
>> corresponding responses.
> 
> Please clarify that the client MUST retry unanswered requests and not
> all "those requests" it pipelined.
> 
> 
>> MUST NOT pipeline on a retry connection until it knows the connection
>> is persistent.
> 
> Is it really possible to know that a connection _is_ persistent? And
> what does that really mean for a connection to be persistent "now"? I
> think all it means is that the connection seems to be "open" -- that the
> sender has not received an error or connection close notification [yet].
> 
> It is possible to know that the connection was persistent (i.e., handled
> multiple messages), but since the server may close an idle (from the
> server point of view) connection at any time, I do not think it is
> possible to know that the next message will reach the server, unless the
> client and the server are coordinating out of band somehow.
> 
> What are we trying to achieve with this requirement? Avoid multiple and
> possibly endless retries? Minimize the chances that a retry will have to
> be retried? Perhaps the MUST can be relaxed or reworded to reflect the
> true intent?
> 
> 
> 
> 
> And here is a list of MUST-level requirements that are missing an
> explicit actor on which the requirement is placed. Most of these should
> be easy to rephrase to place the requirement on the intended actor
> (e.g., "A proxy MUST" instead of "header field MUST":
> 
>> An unrecognized header field received by a proxy MUST be forwarded
>> downstream
> 
>> The host MUST NOT be empty; if an "http" URI is received with an
>> empty host, then it MUST be rejected as invalid.
> 
>> the TCP connection MUST be secured,
> 
>> These special characters MUST be in a quoted string
> 
>> the message framing is invalid and MUST be treated as an error
> 
>> a response message received by a user agent, it MUST be treated as an
>> error
> 
>> The trailer MUST NOT contain fields
> 
>> the Host field-value MUST be identical
> 
>> the Host header field MUST be sent with an empty field-value.
> 
>> The "Via" header field MUST be sent by a proxy
> 
>> the connection MUST be closed after the current request/response is
>> complete
> 
>> all messages on a connection MUST have a self-defined message length
> 
>> the first action after changing the protocol MUST be a response
> 
> Please be careful with "send" and "generate" when fixing the above
> actorless rules so that the proxies do not accidentally become
> responsible for policing traffic where unnecessary.
> 
> 
> Thank you,
> 
> Alex.
> 
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Tuesday, 7 May 2013 04:55:13 UTC