Update references to RFC2616.

net/http/http_stream_parser.cc

Index: net/http/http_stream_parser.cc
diff --git a/net/http/http_stream_parser.cc b/net/http/http_stream_parser.cc
index 46a1702674c43a4905e43e3af4896bd8de95fef8..684ea860d34ec62a8ad95d9e81228eb667ccd091 100644
--- a/net/http/http_stream_parser.cc
+++ b/net/http/http_stream_parser.cc
@@ -963,16 +963,33 @@ void HttpStreamParser::CalculateResponseBodySize() {
   // Figure how to determine EOF:
 
   // For certain responses, we know the content length is always 0. From
-  // RFC 2616 Section 4.3 Message Body:
+  // RFC 7230 Section 3.3 Message Body:
   //
-  // For response messages, whether or not a message-body is included with
-  // a message is dependent on both the request method and the response
-  // status code (section 6.1.1). All responses to the HEAD request method
-  // MUST NOT include a message-body, even though the presence of entity-
-  // header fields might lead one to believe they do. All 1xx
-  // (informational), 204 (no content), and 304 (not modified) responses
-  // MUST NOT include a message-body. All other responses do include a
-  // message-body, although it MAY be of zero length.
+  // The presence of a message body in a response depends on both the
+  // request method to which it is responding and the response status code
+  // (Section 3.1.2).  Responses to the HEAD request method (Section 4.3.2
+  // of [RFC7231]) never include a message body because the associated
+  // response header fields (e.g., Transfer-Encoding, Content-Length,
+  // etc.), if present, indicate only what their values would have been if
+  // the request method had been GET (Section 4.3.1 of [RFC7231]). 2xx
+  // (Successful) responses to a CONNECT request method (Section 4.3.6 of
+  // [RFC7231]) switch to tunnel mode instead of having a message body.

[wtc, 2015/06/05 01:51:05]

I studied the relevant code. It seems useful to set response_body_length_
to 0 for a 2xx (successful) response to a CONNECT request method if we
ever support a protocol where the server speaks first after the proxy
tunnel is established. Right now we only do TLS/SSL and the client speaks
first in a TLS/SSL handshake.

I would hate to add a TODO comment during the Fixit. But I won't have time
to handle the consequences of this change. So I suggest we not change this.
Alternatively, can you suggest a person who can drive this to completion?

The code we would need to add is simple:

  if (request_->method == "CONNECT" && response_->headers->response_code() ==
200)
    response_body_length_ = 0;

[Bence, 2015/06/05 11:28:33]

I think this will naturally come up if someone wants to implement such a
protocol, so I wouldn't worry about future-proofing at this point.

+  // All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
+  // responses do not include a message body.  All other responses do
+  // include a message body, although the body might be of zero length.
+  //
+  // From RFC 7231 Section 6.3.6 205 Reset Content:
+  //
+  // Since the 205 status code implies that no additional content will be
+  // provided, a server MUST NOT generate a payload in a 205 response.  In
+  // other words, a server MUST do one of the following for a 205

[wtc, 2015/06/05 01:51:04]

Chris: do you think we need to quote the entire paragraph? I think quoting the
first sentence is enough.

[Bence, 2015/06/05 11:28:33]

I think the first sentence is enough.  Even better, for the purposes of this
method, you could possibly combine it with the previous paragraph: "All 1xx
(informational), 204 (No Content), 205 (Reset Content), and 304 (Not Modified)
responses...".

[cbentzel, 2015/06/05 14:07:30]

Agree that first sentence is enough. Thanks for finding this quote!

[wtc, 2015/06/05 17:28:50]

Done.

+  // response: a) indicate a zero-length body for the response by
+  // including a Content-Length header field with a value of 0; b)
+  // indicate a zero-length payload for the response by including a
+  // Transfer-Encoding header field with a value of chunked and a message
+  // body consisting of a single chunk of zero-length; or, c) close the
+  // connection immediately after sending the blank line terminating the
+  // header section.
   if (response_->headers->response_code() / 100 == 1) {
     response_body_length_ = 0;
   } else {