* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #339 (closed editorial: incorporated)

Opened 2 years ago

Last modified 23 months ago

Misc editorial feedback for consideration in p1

Reported by: mnot@pobox.com Owned by: julian.reschke@gmx.de
Priority: normal Milestone: 21
Component: p1-messaging Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/4E70FA07BAF76943AAF86F5F6368607803B6958F25@ITUPC-EX1MBOX.UniNet.unisa.edu.au

Description

  1. Section 6.1.1 Purpose

Change Type: Editorial clarification Rationale: This section includes a list of advantages of using persistent HTTP connections. The third and fourth points state: “Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to determine the congestion state of the network.” “Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake.” These points concentrate on the opening phase of TCP causing delay, because of the 3 way handshake, but equally important is the graceful closing phase, which requires handshakes in both directions (FIN followed by ACK for each side), and the holding of the TIMEWAIT state, causing further delay. Because it is equally important to the closing phase, we feel it is useful to include this point in the list of advantages. Proposed Replacement text: Third point: “Network congestion is reduced by eliminating the packets associated with TCP’s three way handshake and graceful close procedures, and by allowing TCP sufficient time to determine the congestion state of the network.” Fourth Point: “Latency on subsequent requests is reduced since there is no time spent in the double handshakes required for gracefully closing TCP connections and holding the TIMEWAIT state, and in TCP's connection opening handshake, when reopening the connection.”

  1. Section 6.1.2 Overall Operation, second paragraph

Change Type: Editorial clarification Rationale: The second paragraph of this section states:

“ Persistent connections provide a mechanism by which a client and a

server can signal the close of a TCP connection. This signaling takes place using the Connection header field (Section 8.1). Once a close has been signaled, the client MUST NOT send any more requests

on that connection.”

The last sentence contains a mandatory requirement that may not be able to be met by a client using pipelining. If the client signals the close, then it is OK. However, if the server signals the close in a response, further pipelined requests may be sent by the client until it receives the response with the close token. Hence we need to rephrase the requirement so that the client can meet it. Proposed Replacement text: Replace the last sentence by: “Once a close has been signaled by the client in a request, or the close token has been received by the client in a response, the client MUST NOT send any more requests on that connection.”

  1. Section 6.1.2.1 Negotiation, second paragraph

Change Type: Editorial clarification Rationale: The second paragraph of this section states:

“ An HTTP/1.1 client MAY expect a connection to remain open, but would

decide to keep it open based on whether the response from a server contains a Connection header field with the connection-token close.”

It is not clear what the intent of this sentence is. Does it imply that on the receipt of a response with a close token, the client will close the connection? Does it also imply that if the response did not contain the close token, then the client would keep the connection open? If this is the intent, then a clearer statement of it would help to exclude other interpretations, as the current text seems to allow the client latitude to close or not on either of these events. Proposed Additional text if the above interpretation is the intent: Add a sentence to clarify the intent at the end of the above quoted sentence: “If the response does not contain the close token the client will keep the connection open, otherwise, on receipt of the close token in the response, the client will close the connection.”

  1. Section 6.1.2.1 Negotiation, third paragraph (second paragraph on page 42)

Change Type: Editorial clarification Rationale: The paragraph states:

“If either the client or the server sends the close token in the

Connection header field, that request becomes the last one for the connection.”

This is similar to item 2 above. The problem is knowing what “that request” is in the case when the server includes the close token and pipelining occurs, and what is intended by the phrase “becomes the last one for the connection”. We expect that the following is the intent:

  1. If the client receives a response with the close token, it will not send any more requests (as in item 2 above); and
  2. Once the server has sent a response with the close token, it will discard any further requests it receives.

Proposed Replacement text, given that previous items 2 and 3 are accepted Replace this sentence by: “Once the server has sent a response with the close token, it will discard any further requests it receives.”

Change History

comment:1 Changed 2 years ago by mnot@pobox.com

  • Owner changed from draft-ietf-httpbis-p1-messaging@tools.ietf.org to fielding@gbiv.com

comment:2 Changed 2 years ago by mnot@pobox.com

  • Owner changed from fielding@gbiv.com to julian.reschke@gmx.de

comment:3 Changed 23 months ago by fielding@gbiv.com

From [1869]:

(editorial) improve bullet on network congestion. Addresses #339

comment:4 Changed 23 months ago by fielding@gbiv.com

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

Thanks for the review.

  1. I did not apply the change to Fourth Point of 6.1.1 because the added text does not impact latency and is already sufficiently noted by the modified third point.

2-4. I fixed these problems when I rewrote the section over the weekend, see [1863]. The prior text was a form of mental torture.

Note: See TracTickets for help on using tickets.