Update references to RFC2616.

net/http/http_stream_parser.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "net/http/http_stream_parser.h"
 
 #include "base/bind.h"
 #include "base/compiler_specific.h"
 #include "base/logging.h"
 #include "base/metrics/histogram_macros.h"
@@ skipping 822 matching lines @@
     // Prevent growing the headers buffer indefinitely.
     if (read_buf_->offset() >= kMaxHeaderBufSize) {
       io_state_ = STATE_DONE;
       return ERR_RESPONSE_HEADERS_TOO_BIG;
     }
   } else {
     CalculateResponseBodySize();
     // If the body is zero length, the caller may not call ReadResponseBody,
     // which is where any extra data is copied to read_buf_, so we move the
     // data here.
     if (response_body_length_ == 0) {

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

This is the code that depends on CalculateResponseBodySize() setting
response_body_length_ to 0 when necessary.

I don't understand why it is necessary to move the extra data to the
beginning of read_buf_.

       int extra_bytes = read_buf_->offset() - end_of_header_offset;
       if (extra_bytes) {
         CHECK_GT(extra_bytes, 0);
         memmove(read_buf_->StartOfBuffer(),
                 read_buf_->StartOfBuffer() + end_of_header_offset,
                 extra_bytes);
       }
       read_buf_->SetCapacity(extra_bytes);
       if (response_->headers->response_code() / 100 == 1) {
         // After processing a 1xx response, the caller will ask for the next
@@ skipping 102 matching lines @@
            << "\n\""
            << " headers = \""
            << GetResponseHeaderLines(*response_->headers.get()) << "\"";
   return OK;
 }
 
 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 {
     switch (response_->headers->response_code()) {
       case 204:  // No Content
       case 205:  // Reset Content
       case 304:  // Not Modified
         response_body_length_ = 0;
         break;
     }
@@ skipping 102 matching lines @@
       request_body->IsInMemory() &&
       request_body->size() > 0) {
     uint64 merged_size = request_headers.size() + request_body->size();
     if (merged_size <= kMaxMergedHeaderAndBodySize)
       return true;
   }
   return false;
 }
 
 }  // namespace net