WGLC: p1 MUSTs

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.

Received on Tuesday, 30 April 2013 18:55:31 UTC