#446 closed editorial (incorporated)
p1 editorial feedback
Reported by: | mnot@… | Owned by: | draft-ietf-httpbis-p1-messaging@… |
---|---|---|---|
Priority: | normal | Milestone: | 23 |
Component: | p1-messaging | Severity: | In WG Last Call |
Keywords: | Cc: |
Description
- 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)
Change History (4)
comment:1 Changed 10 years ago by fielding@…
comment:2 Changed 10 years ago by fielding@…
comment:3 Changed 10 years ago by fielding@…
- Milestone changed from unassigned to 23
- Resolution set to incorporated
- Status changed from new to closed
comment:4 Changed 10 years ago by julian.reschke@…
Note: See
TracTickets for help on using
tickets.
Done.
Done.
Done. The latter part is better described by the next paragraph, so I've truncated that.
Done.
No, any other protocols is intended here.
Done.
Done.
Done.
No, this is also talking about the order of responses corresponding to the order of requests.
Thousands is the right order of magnitude here. "many" doesn't say anything.
This is not a requirement ... it is just stating what most clients do.
Noted as a hypothetical example.
Done.
Done.
Maybe, but it should be raised as a separate issue for all parts.