Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#478 closed editorial (incorporated)

MUSTs and other feedback

Reported by: mnot@… Owned by: draft-ietf-httpbis-p2-semantics@…
Priority: normal Milestone: 24
Component: p2-semantics Severity: In WG Last Call
Keywords: Cc:

Description (last modified by mnot@…)

[editors, please switch to 'design' if you feel it is necessary]

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.

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.

Change History (4)

comment:1 Changed 7 years ago by mnot@…

  • Description modified (diff)

comment:2 Changed 6 years ago by fielding@…

From [2342]:

Many changes to properly target MUST requirements by role; addresses #478

comment:3 Changed 6 years ago by fielding@…

  • Milestone changed from unassigned to 24
  • Resolution set to incorporated
  • Status changed from new to closed

Details for [2342]:

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 :-).

Changed to "until the tunnel is closed".

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.

Moved, fixed, and rephrased to "A tunnel is closed when ..."

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"?

Fixed.

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"?

No, the first set applies to proxies that want to use 100-continue for their own reasons.

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?

Changed to

If the received Max-Forwards value is greater than zero, the intermediary MUST generate an updated Max-Forwards field in the forwarded message with a field-value that is the lesser of: a) the received value decremented by one (1), or b) the recipient's maximum supported value for Max-Forwards.

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

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

Fixed in prior commit.

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! :-)

Fixed.

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".

Fixed.

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

Fixed.

then the resource MUST disable or disallow that action

resource owner

The Expect header field MUST be forwarded

Fixed.

the forwarded message MUST contain an updated Max-Forwards field

Fixed above.

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

Fixed.

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

Fixed.

comment:4 Changed 6 years ago by julian.reschke@…

From [2343]:

Note change for [2342] (see #478)

Note: See TracTickets for help on using tickets.