p1 editorial feedback

[mnot@…]

• 2.2 "... requirements that an automated action be confirmed by the user before proceeding can be met via advance configuration choices..." s/can/might/ (don't imply that it's a closed set)

• 2.2 Add text to indicate that the chain of intermediaries isn't necessarily fixed; i.e., that while it goes through "C" this time, the next request might go direct to origin, or through "D", or...

• 2.3 'A "gateway"... is a receiving agent that acts a a layer above some other server(s) and translates the received requests to the underlying server's protocol.' "layer" "receiving agent" and "underlying" are awkward here. Suggest:

""" A "gateway" (a.k.a., "reverse proxy") is a server that acts as an origin server, but translates received requests and forwards them to another server or servers, using any protocol (possibly HTTP). """

• 2.3 "MUST implement the Connection and Via header fields for both connections." --> "... header fields for both inbound and outbound connections."

• 2.7.1 "Other protocols might also be used..." -> "Other transport protocols might also be used..."

• 4.3 "For chained requests..." -> "For requests from an intermediary..."

• 5.2 "If the client has a response cache and the request semantics can be satisfied by a cache ([Part6]), then the request is usually directed to the cache first." --> "If the client has a HTTP cache [Part6] and the request can be satisfied by it, then the request is usually directed there first." (simplify, simplify)

• 5.7.2 "A transforming proxy MUST preserve the message payload..." "MUST NOT modify" would be clearer here.

• 6. "HTTP only presumes a reliable transport with in-order delivery of requests and the corresponding responses." This isn't really well-stated; the important thing is that the data transport itself is in-order, because requests and responses themselves can be chunked into multiple messages. Suggest:

"HTTP only presumes a reliable, bi-directional transport with in-order delivery."

• 6. "Most severs are designed to maintain thousands of concurrent connections.." s/thousands/many/

• 6. "Most clients maintain multiple connections in parallel..." --> "Clients MAY maintain multiple connections in parallel..."

• 6.7 uses unregistered upgrade tokens in the example; this should be noted.

• 6.7 There should be a full example of an Upgrade header in a request and in a response.

• 8.3 There should be an appropriate reference to RFC6585 here for 431 Request Header Fields Too Large.

• A.2 Is there any particular ordering here? Perhaps they should be ordered by section? (same for other parts)

[fielding@…]

2.2 "... requirements that an automated action be confirmed by the user before proceeding can be met via advance configuration choices..." s/can/might/ (don't imply that it's a closed set)

Done.

2.2 Add text to indicate that the chain of intermediaries isn't necessarily fixed; i.e., that while it goes through "C" this time, the next request might go direct to origin, or through "D", or...

Done.

2.3 'A "gateway"... is a receiving agent that acts a a layer above some other server(s) and translates the received requests to the underlying server's protocol.' "layer" "receiving agent" and "underlying" are awkward here. Suggest: A "gateway" (a.k.a., "reverse proxy") is a server that acts as an origin server, but translates received requests and forwards them to another server or servers, using any protocol (possibly HTTP).

Done. The latter part is better described by the next paragraph, so I've truncated that.

2.3 "MUST implement the Connection and Via header fields for both connections." --> "... header fields for both inbound and outbound connections."

Done.

2.7.1 "Other protocols might also be used..." -> "Other transport protocols might also be used..."

No, any other protocols is intended here.

4.3 "For chained requests..." -> "For requests from an intermediary..."

Done.

5.2 "If the client has a response cache and the request semantics can be satisfied by a cache ([Part6]), then the request is usually directed to the cache first." --> "If the client has a HTTP cache [Part6] and the request can be satisfied by it, then the request is usually directed there first." (simplify, simplify)

Done.

5.7.2 "A transforming proxy MUST preserve the message payload..." "MUST NOT modify" would be clearer here.

Done.

6.0 "HTTP only presumes a reliable transport with in-order delivery of requests and the corresponding responses." This isn't really well-stated; the important thing is that the data transport itself is in-order, because requests and responses themselves can be chunked into multiple messages. Suggest: HTTP only presumes a reliable, bi-directional transport with in-order delivery.

No, this is also talking about the order of responses corresponding to the order of requests.

6.0 "Most servers are designed to maintain thousands of concurrent connections.." s/thousands/many/

Thousands is the right order of magnitude here. "many" doesn't say anything.

6.0 "Most clients maintain multiple connections in parallel..." --> "Clients MAY maintain multiple connections in parallel..."

This is not a requirement ... it is just stating what most clients do.

6.7 uses unregistered upgrade tokens in the example; this should be noted.

Noted as a hypothetical example.

6.7 There should be a full example of an Upgrade header in a request and in a response.

Done.

8.3 There should be an appropriate reference to RFC6585 here for 431 Request Header Fields Too Large.

Done.

A.2 Is there any particular ordering here? Perhaps they should be ordered by section? (same for other parts)

Maybe, but it should be raised as a separate issue for all parts.

[fielding@…]

From [2270]:

addresses #446 p1 editorial feedback

[julian.reschke@…]

From [2271]:

change log updated (see #446)