Subject: WGLC: p1 MUSTs

From: Alex Rousskov <[email-masked]>
Date: Tue, 30 Apr 2013 12:54:54 -0600

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.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 30 Apr 2013 21:40:16 +0200

Hello Alex,

That was quite a long mail, I think it's more efficient next time to split
this into multiple parts to help people respond to some parts only. I've
read it all, and for a few of them I had no opinion but I gave mine when
possible.

> _generation_ and not forwarding here.

The notion of "forwarding" is something very recent here. Since 2616, we
only had receivers and senders. And even here as you can see we're clearly
talking about a sender. At most places, a sender is also a forwarder, which
can cause confusion. The fact that you're specifically talking about
forwarding here means that the text is clear on the subject, so probably
we should leave it in order to avoid confusion.

> definition of "process" that clarifies this?

I think you got it right. Or maybe "used" would fit better for you ?

> "interpreted" issue mentioned above.

Interesting. I think "processed" covers "forwarded" here. Typically
a gateway would not necessarily know how to validate certain header
field values that it does not uses but still has to forward.

> corresponding ABNF protocol element rules applicable to the recipient's

I agree this looks better.

(...)
> (but see below for a related missing MUST).

Be prepared means that it's their responsibility to handle this correctly,
including rejecting the request. However they "must be prepared" to face
URIs too large for them. Some servers used to crash when dealing with too
large URIs you know...

> Please insert a second MUST after "and": "and MUST respond".

Indeed.

> headers that a proxy may not understand (but may still want to combine

Indeed we should have a MAY here in my opinion to improve clarity.

> See above for discussion of a similar MUST that applies to URIs of

Same as above for me and for same reasons.

> body, the sender still MUST NOT apply chunked more than once!

No I think it's the wording which is wrong. The intent was to ensure that
we never chunk more than once. It's as always the passive form which causes
trouble because you never know if it applies to what you see or what you do.
I'd suggest something like this :

  If sender applies chunked encoding to a payload body, it MUST NOT apply
  it more than once.

> combination is also not allowed.

Maybe this could be moved to the part that says that chunked is always
the last encoding, and summarized into a single sentence. Eg:

  Chunked encoding MUST NOT be apply more than once on a message payload
  and must always be last.

> hop-by-hop mechanism, proxies ought to forward Trailers whenever

I'm having a doubt on this one since, in my opinion, trailers are always
optional since we never knwo whether they'll correctly be interpreted.
However I agree that a proxy or gateway should always forward them.

> absolute-form for all requests" by stripping URIs as they forward them?

Yes, probably.

(...)
> Including a CONNECT request message?

Yes, and indeed I've seen at least one proxy do that in the past. It's not
a problem to have a "close" with a CONNECT, since CONNECT simply transfers
messages of infinite length in both directions, which are only terminated
by a close. Also, when sending a CONNECT to an authenticating proxy, you'd
rather use "Connection: close" if you think you'll have to reauthenticate
using a new connection when facing a 407.

> MUST be prepared to retry but does not have to retry? Or MUST retry?

Same as above, "must be prepared" here means that it must make valid
choices even before facing the failure (eg: not send non-idempotent
requests).

> all "those requests" it pipelined.

Good point.

> Is it really possible to know that a connection _is_ persistent?

Well, it's by definition until a "connection: close" response is seen.
Persistent does not mean forever, so if no "close" is seen and the
connection is closed by the server just after the response, it was a
persistent one for too short a time for you to reuse it.

> And

Which is the point for not sending non-idempotent requests on such connections.

> be retried? Perhaps the MUST can be relaxed or reworded to reflect the

I don't know.

> > An unrecognized header field received by a proxy MUST be forwarded

Here the only actor is the proxy.

> > empty host, then it MUST be rejected as invalid.

I think this one is not ambiguous as it describes a protocol violation
which must end up with a 400.

> > These special characters MUST be in a quoted string

OK for these ones.

> > the message framing is invalid and MUST be treated as an error

"MUST be treated" indicates the actor is the message receiver.

> > a response message received by a user agent, it MUST be treated as an

here again.

> > the Host header field MUST be sent with an empty field-value.

I on't have the context in mind but all 3 above again indicate how to
detect protocol violations.

> > The "Via" header field MUST be sent by a proxy

"MUST ... by" so the actor is the proxy.

> > the connection MUST be closed after the current request/response is

Possible doubt here indeed.

> > all messages on a connection MUST have a self-defined message length

Ambiguous as well.

> > the first action after changing the protocol MUST be a response

Here I think the intent is on the server (it's about Upgrade+101 I guess).

> responsible for policing traffic where unnecessary.

In my opinion, "send" includes "forward" and "generate", which is the
reason why there are a number of "except" or "unless" in the wording.
Note that some intermediaries just blindly pass data blocks which is
clearly "forwarding", but other ones parse, build structures and rebuild
requests from these structures, so it's more "recv+send" than "forward",
eventhough they don't necessarily understand what is there.

Maybe some additional definitions are needed at the beginning to clarify
this ?

Thanks,
Willy

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 30 Apr 2013 14:46:01 -0600

Hello,

    These comments are based on the "latest" snapshot dated Tue 30 Apr
2013 07:24:09 AM MDT at
https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html

> The CONNECT method requests that the recipient establish a tunnel to
> the destination origin server [...], until the connection is closed.

The "until the connection is closed" part is misleading and inaccurate.

There are two connections in a CONNECT tunnel: (a) between a CONNECT
sender and CONNECT recipient and (2) between CONNECT recipient the the
next HTTP hop. The tunnel termination condition is rather complex and is
detailed later in the same section. It may be a good idea to drop the
"until..." part. At least I cannot suggest a way to describe it
correctly as an ending of an already long sentence :-).

> When a tunnel intermediary detects that either side has closed its
> connection, any outstanding data that came from that side will first
> be sent to the other side and then the intermediary will close both
> connections. If there is outstanding data left undelivered, that data
> will be discarded.

These "will"s should be rephrased as intermediary MUSTs IMO. I also
suggest moving them higher, before the informal risk discussion.

> A client MUST NOT send header fields in a TRACE request containing
> sensitive data

The above rule seems too onerous to proxies. Replace "MUST NOT send"
with "MUST NOT generate"?

> 5.1.1.1 Use of the 100 (Continue) Status
> Requirements for HTTP/1.1 clients:
...
> Requirements for HTTP/1.1 proxies:

Should we explicitly exclude proxies from the first group of
requirements by saying "Requirements for user agents" instead of
"Requirements for clients"?

> MUST contain an updated Max-Forwards field with a value decremented by one (1).

A lot of proxies violate this MUST because they cannot grok and, hence,
cannot decrement large integer values. Interoperability problems might
happen when a client generates Max-Forwards with a maximum value it can
store (e.g., to count the number of hops to the origin server) but the
proxy cannot store such a large value (e.g., 64bit vs 32bit).

Perhaps we can relax this rule by allowing proxies to decrement by "at
least one", so that a huge value can be replaced with the maximum value
the proxy can represent?

> A client MUST be prepared to accept one or more 1xx

Drop "be prepared" to demand acceptance rather than preparedness?

> Proxies MUST forward 1xx responses, unless the connection between the
> proxy and its client has been closed,

This "unless" clause should be dropped as implied. Otherwise, we would
have to add it to every "MUST forward" requirement! :-)

> A sender MUST generate the IMF-fixdate format when sending an
> HTTP-date value in a header field.

Please polish to remove the implication that proxies must fix dates when
forwarding HTTP-date values. For example: "A sender MUST use the
IMF-fixdate format when generating a header field containing an
HTTP-date value".

Or perhaps simply: "A sender MUST generate HTTP-date values in the
IMF-fixdate format".

And here is a list of 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":

> the content codings MUST be listed in the order in which they were applied

> then the resource MUST disable or disallow that action

> The Expect header field MUST be forwarded

> the forwarded message MUST contain an updated Max-Forwards field

> The Max-Forwards header field MAY be ignored for all other request methods. 

> a response with an unrecognized status code MUST NOT be cached. 

Thank you,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 30 Apr 2013 16:53:23 -0600

> read it all, and for a few of them I had no opinion but I gave mine when

I struggled with the format. The Last Call instructions say "Issues that
you believe to be editorial in nature (e.g., typos, suggested
re-phrasing) can be grouped together in a single e-mail" and that is
what I did because I believe these problems are editorial in nature.

> The fact that you're specifically talking about

Both the requirement text and I are talking specifically about
generation (MUST NOT _generate_), not forwarding. The text is clear with
regard to generation, but contains an "[applicable] elements" scope
restriction that should be dropped IMO.

>   If sender applies chunked encoding to a payload body, it MUST NOT apply

Yes, and you can remove the precondition from your wording as well, to
simplify: A sender MUST NOT generate messages with multiple chunked
encodings. Again, the precondition (i.e., the "if" part) does not help here.

> choices even before facing the failure (eg: not send non-idempotent

My point was not about valid choices before facing the failure (I think
those choices are covered by different rules) but about required actions
after the failure (i.e., retry):

- Your proxy is not compliant because it does not retry failed pipelined
GETs!

- No, my proxy is compliant: You see, it was prepared to retry those
GETs as required. Trust me, it was! I checked the logs, and they say
"prepared to retry using connection X". Unfortunately, it did not retry
them when they actually failed (that backup connection X got closed
while they were being sent), but there is no requirement to retry, right?

- You are right. Time to file errata...

The "be prepared" part might be useful in an informal explanation but it
is invalidating the intended formal requirement here (to retry).

> In my opinion, "send" includes "forward" and "generate", 

Yes. That is one of the reasons why I am asking to rephrase these rules
even if the right actor can sometimes be guessed. Some of the polished
rules will use "send", but some may end up using "generate" when
polished. The difference is important.

> this?

Somebody already added those definitions and adjusted many rules to use
them (thank you, somebody!). However, some requirements still need to be
polished to use the right words. Making actors explicit helps with that.

Thank you,

Alex.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 May 2013 01:14:49 +0200

> what I did because I believe these problems are editorial in nature.

OK.

> restriction that should be dropped IMO.

Got it now, yes I think you're right.

> encodings. Again, the precondition (i.e., the "if" part) does not help here.

I know I'm a bit nit-picking, but it's not exactly the same. You're saying
that it must not generate such messages, not that it should not apply the
encoding multiple times. So that does not immediately translate into "do it
only once", but could as well be "drop the message" or "don't use chunked
encoding at all". Maybe this one would be better then :

  A sender MUST NOT apply chunked encoding more than once to a message body.

> is invalidating the intended formal requirement here (to retry).

I get your point, but then if it's about compliance, I suspect the issue
is that the "MUST" should not be a normative one, just a "must".

> polished. The difference is important.

I agree the difference is important, and from memory, this difference
started to become clear something like 1-2 years ago. I'm sure there
are some places where it's really clear yet as the intermediary will
sometimes be considered as a sender and sometimes as a receiver, and
the forwarding role might not be present (nor relevant) everywhere.
But in general, I think that quite a good cleanup was done recently.

> them (thank you, somebody!).

OK, I didn't have it open in front of me to check when I replied.

> However, some requirements still need to be

Agreed, but you might have noticed that replacing the passive forms with
active ones tends to change large amounts of text. So the temptation is
huge sometimes not to rewrite a whole paragraph to introduce roles when
a MUST becomes a SHOULD or something like this.

Cheers,
Willy

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 30 Apr 2013 17:22:39 -0600

On 04/30/2013 01:40 PM, Willy Tarreau wrote:

>>> A client [...] MUST NOT pipeline on a retry connection until it
>>> knows the connection is persistent.

> Well, it's by definition until a "connection: close" response is seen.

You are right. My complains about not being able to know whether a
connection is persistent were invalid because the rules in "p1 6.3
Persistence" determine whether the connection is considered persistent.
However, there are two related problems with those rules:

a) They do not apply to connections on which no responses have been
received.

b) They do not mention that a persistent connection may close without
warning at any time.

Let's start with (a): To know that a connection "is persistent", the
client has to receive a response on that connection. This implies that
the client MUST NOT retry a failed pipelined request on a connection it
just opened. What if there are no other connections and not other
requests to send, except for the failed one? Is the proxy going to be
stuck because it is not allowed to use a new connection to retry the
failed pipeline request?

To fix this, I think we have to add a rule that declares a freshly
opened, unused connection "persistent" OR allow retries on such
connections without declaring them persistent.

As for (b), depending on the intent of this MIST NOT, it may be useful
to discourage developers from using connections that were idle for a
long time for retries because those connections are more likely to fail
when [re]used.

Thank you,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 30 Apr 2013 18:33:14 -0600

Hello,

    These comments are based on the "latest" snapshot dated Tue 30 Apr
2013 06:59:03 AM MDT at
https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p4-conditional.html

I hope these comments can be addressed by editors alone.

> The If-Match condition is met if and only if any of the entity-tags
> listed in the If-Match field value match the entity-tag of the
> selected representation using the weak comparison function (as per
> Section 2.3.2), or if "*" is given and any current representation
> exists for the target resource.

The "if and only if ... or if ..." construction looks funny. It is kind
of correct because the first part applies to the non-* condition and the
second part applies to the * condition, but still... Please consider
dropping either "and only if" or the "if" in "or if".

Can a proxy with an empty cache determine whether "any current
representation exists for the target resource" without forwarding the
request to the origin server? In other words, does "exists" mean "exists
in the proxy cache" or "exists on the origin server"? Perhaps you can
add some test to clarify the scope of resource existence here from the
caching proxy point of view.

The same two concerns apply to the If-None-Match section.

Here is a list of requirement-like statements that seem to be missing
MUST/SHOULD/MAY keywords to make them formal requirements and indicate
the level of those requirements:

> Preconditions are ignored if the server determines that an error or
> redirect response applies before they are evaluated.

> The conditional request header fields defined by this specification
> are ignored for request methods that never involve the selection or
> modification of a selected representation

> The general rule of conditional precedence is that exact match
> conditions are ...

> Specifically, the fields defined by this specification are evaluated
> as follows:

Please consider rephrasing the above using RFC 2119 keywords and, where
applicable, giving them explicit actors.

Thank you,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 30 Apr 2013 19:18:49 -0600

Hello,

    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/p5-range.html

I hope these comments are "editorial in nature".

> Clients MUST NOT use an entity-tag marked as weak in an If-Range
> field value and MUST NOT use a Last-Modified date ...

Please replace "use" with "generate" to explicitly exclude proxies from
policing these headers (i.e., to allow proxies to forward these headers
"as is"). This was already done for other If-Range header rules, but
these two MUST NOTs have slipped through the cracks.

> A client that cannot process a multipart/byteranges response MUST NOT
> ask for multiple ranges in a single request.

A similar concern here for "MUST NOT ask". Please reword the above to
use "MUST NOT generate".

This is especially important because a proxy may not be able to fully
"process" a multipart/byteranges response (whatever that means) but it
can still forward a request for multiple ranges and correctly forward
the 206 response back to the client because HTTPbis no longer allows
multipart/byteranges media type to determine the message body length.

> 4.1 206 Partial Content

Since HTTPbis no longer allows multipart/byteranges media type to
determine the message body length, perhaps it would be a good idea to
explicitly mention that a server MAY generate a 206 Partial Content
response (with single or multiple ranges) without a Content-Length
header and may use chunked encoding? I bet many clients will break when
this starts happening, and there are currently no examples or warnings
that would prepare developers for that possibility.

Thank you,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 30 Apr 2013 22:56:48 -0600

Hello,

    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/p6-cache.html

I hope these comments are editorial in nature.

> senders MUST NOT send delta-seconds with a value greater than 2147483648. 

Please use "MUST NOT generate" instead. The proxies should not be
required to police these values.

> For a presented request, a cache MUST NOT send a stored response

This is awkward because many caches never actually send stored responses
because they add or modify Connection, Transfer-Encoding, and other
hop-by-hop headers to/in a store response. Please consider something
like "a cache MUST NOT generate a reply using a stored response" instead.

> A cache MUST NOT send a stale response

Please use "MUST NOT generate". A cache may still send a stale response
by forwarding it. There is already some text implying that later in the
section (see below) but that text belongs to a Warning-generation
context, so it is better to be explicit here.

> the cache can forward it to the requesting client without adding a new Warning 

Use MAY instead of "can"?

> If an implementation sends a message with one or more Warning header
> fields to a receiver whose version is HTTP/1.0 or lower, then the
> sender MUST include in each warning-value a warn-date that matches
> the Date header field in the message

> If a system receives a message with a warning-value that includes a
> warn-date, and that warn-date is different from the Date value in the
> response, then that warning-value MUST be deleted from the message
> before storing, forwarding, or using it.

Please note that the above MUST requirements can be interpreted to apply
to all intermediaries, even those that do not support caching. We have
received many complaints from non-caching proxy implementors unknowingly
violating these MUSTs and having to implement these complex
manipulations that are seemingly irrelevant to their products.

You may also want to replace "implementation" and "system" with sender
and recipient to use consistent terminology. If these rules are specific
to response messages, then using "server" and "client" would be even better.

If the above requirements are only meant for origin server and user
agents, and not all senders and recipients, please fix the actors
accordingly.

> A system receiving this warning MUST NOT take any automated action,
> besides presenting the warning to the user.

In this case, the "system" is probably the "user agent" since
"presenting the warning to the user" is mentioned. Same for 299
"Miscellaneous Persistent Warning".

Please search the whole text for similar "implementation" and "system"
terminology "sprawl".

And here is a list of requirements that are missing an explicit actor on
which the requirement is placed. Even though it is possible to guess the
actor in most cases, these should be easy to rephrase to place the
requirement on the intended actor explicitly (e.g., "A cache MUST"
instead of "a response MUST"):

> the new response MUST NOT be used to update any stored responses.

> the no-cache request pragma-directive MUST have the same effect on
> caches

> warning-value MUST be deleted from the message before storing,
> forwarding, or using it

Thank you,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 30 Apr 2013 23:09:17 -0600

Hello,

    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/p7-auth.html

I hope these issues are "editorial in nature".

> For historical reasons, senders MUST only use the quoted-string syntax.

Perhaps this can be relaxed to "MUST only generate", especially since
another MUST prohibits proxies from modifying WWW-Authenticate and
Authorization header fields.

And here is a list of requirements that are missing an explicit actor on
which the requirement is placed. Even though it is often possible to
guess the actor, most of these should be easy to rephrase to place the
requirement on the intended actor explicitly (e.g., "A proxy MUST"
instead of "a header field MUST":

> each parameter name MUST only occur once per challenge

> This response MUST include a WWW-Authenticate header

> The 407 (Proxy Authentication Required) response message [...] MUST
> include a Proxy-Authenticate header field

> information necessary to authenticate a request MUST be provided in
> the request

> It MUST be included as part of a 407 (Proxy Authentication Required)
> response.

> It MUST be included in 401 (Unauthorized) response messages

Thank you,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 30 Apr 2013 23:53:28 -0600

Hello,

    When talking about a Content-Length header field with multiple
identical values, Part 1 Section 3.3.2 of HTTPbis says:

> the recipient MUST either reject the message as invalid or
> replace the duplicated field-values with a single valid
> Content-Length field containing that decimal value prior to
> determining the message body length.

It is not clear whether "recipient MUST replace" (a requirement on the
recipient) also implies that "a sender MUST replace [...] when
forwarding the message" (a requirement on the sender). This issue has
been raised on 2011/11/28, but the discussion diverged, and I could not
tell whether there was a consensus on what the correct interpretation is.

Please decide whether a proxy MUST "fix" such Content-Length headers
when forwarding the message and adjust the above text to clarify one way
or another.

Thank you,

Alex.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 May 2013 08:52:26 +0200

> a) They do not apply to connections on which no responses have been

I think that it was the reason why it's suggested somewhere that pipelining
should only be done on connections that we know are persistent (ie after a
first response), but that defeats a bit the usefulness of pipelining. Some
clients might probably cache information about what server supports it though.

> b) They do not mention that a persistent connection may close without

I'm almost sure it's mentionned somewhere, in the part detailing how to
perform retries.

> just opened.

I don't understand the goal of adding this. If every component in the
chain works correctly, you don't even need to know if the connection
will be persistent, you connect, flood the link with requests and wait
for responses. If it closes before the last response, you know which
ones need to be retried. The suggestions about persistent connections
are just hints to reduce the risk of breaking connections when some
component in the chain don't work well. But the spec should not make
it normative that there are random implementation bugs everywhere and
as such everyone should refrain from doing optimal things if they
know that in some contexts it's perfectly OK.

For example, if your client is installed on a smartphone sold by an
operator which uses transparent proxies as the first element in the
chain, the vendor can have a 100% confidence that pipelining works
and that all connections will be persistent, so you want the client
to assume that for each connection and send whatever it has on each
of them without waiting for a very long round trip to get the first
response.

> What if there are no other connections and not other

We don't care about this, since the only way to know if the connection is
usable is to try to use it. You have two possibilities then :
  - send a dummy request (eg: OPTIONS *)
  - send a real request

Since the real request is supposed to be idempotent, you don't need to waste
your time sending the dummy request.

I know some applications which use a single connection which lasts a full
day and which sees from 1 to 100 requests on it a day. The time to set up
this connection can be huge because for some clients it requires manual
intervention (cert on a smart card). In such contexts, when you know
everything is compliant in the chain, you don't want to abort these
connections just because they remained unused for 5 hours :-)

Regards,
Willy