Re: WGLC: p1 MUSTs

Mark Nottingham <mnot@mnot.net> Tue, 07 May 2013 04:56 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C2C21F8FDC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 6 May 2013 21:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level:
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHNn4S6Tgfb3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 6 May 2013 21:56:30 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 54C0421F8617 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 6 May 2013 21:56:30 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UZZvv-0002H9-U3 for ietf-http-wg-dist@listhub.w3.org; Tue, 07 May 2013 04:55:23 +0000
Resent-Date: Tue, 07 May 2013 04:55:23 +0000
Resent-Message-Id: <E1UZZvv-0002H9-U3@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UZZvl-0002Fa-FF for ietf-http-wg@listhub.w3.org; Tue, 07 May 2013 04:55:13 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UZZvh-0006uT-M0 for ietf-http-wg@w3.org; Tue, 07 May 2013 04:55:13 +0000
Received: from [192.168.1.80] (unknown [118.209.105.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3866722E25B; Tue, 7 May 2013 00:54:46 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <5180137E.2040603@measurement-factory.com>
Date: Tue, 7 May 2013 14:54:43 +1000
Cc: IETF HTTP WG <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B07C07A-2B20-43E6-9949-F54C2D80B7E8@mnot.net>
References: <D69329FD-7456-46C5-BE24-6E7EE7E48C39@mnot.net> <5180137E.2040603@measurement-factory.com>
To: Alex Rousskov <rousskov@measurement-factory.com>
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-2.427, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UZZvh-0006uT-M0 b682ce3bcd4acb3c27aa4f06e6d7f7c6
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WGLC: p1 MUSTs
Archived-At: <http://www.w3.org/mid/5B07C07A-2B20-43E6-9949-F54C2D80B7E8@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17854
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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/