mnot
commented
11 years ago @mnot changed description from:
[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.
to:
[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 dataThe 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 1xxDrop "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.
[editors, please switch to 'design' if you feel it is necessary]
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 :-).
These "will"s should be rephrased as intermediary MUSTs IMO. I also suggest moving them higher, before the informal risk discussion.
The above rule seems too onerous to proxies. Replace "MUST NOT send" with "MUST NOT generate"?
Should we explicitly exclude proxies from the first group of requirements by saying "Requirements for user agents" instead of "Requirements for clients"?
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?
Drop "be prepared" to demand acceptance rather than preparedness?
This "unless" clause should be dropped as implied. Otherwise, we would have to add it to every "MUST forward" requirement! :-)
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":
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.
Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/478