Support for new data reduction proxy via header

chrome/browser/net/spdyproxy/data_reduction_proxy_settings.cc

Index: chrome/browser/net/spdyproxy/data_reduction_proxy_settings.cc
diff --git a/chrome/browser/net/spdyproxy/data_reduction_proxy_settings.cc b/chrome/browser/net/spdyproxy/data_reduction_proxy_settings.cc
index c8aa7c9c53e782c0c66160433e38d7038d850c76..7e3af65c07672c6a7dd4e8eada41c090f552cee7 100644
--- a/chrome/browser/net/spdyproxy/data_reduction_proxy_settings.cc
+++ b/chrome/browser/net/spdyproxy/data_reduction_proxy_settings.cc
@@ -209,12 +209,32 @@ bool DataReductionProxySettings::IsPreconnectHintingAllowed() {
 
 // static
 bool DataReductionProxySettings::WasFetchedViaProxy(
-    const net::HttpResponseHeaders* headers) {
-  const char kChromeProxyViaValue[] = "1.1 Chrome Compression Proxy";
+    const net::HttpResponseHeaders* response_headers) {
+  if (!response_headers) {
+    return false;
+  }
+
+  const size_t kVersionSize = 4;
+  const char kDataReductionProxyViaValue[] = "Chrome-Compression-Proxy";

[mef, 2014/02/07 20:33:25]

Any particular reason to skip version? 

Also, I think it may make sense to consistently call it either
'Data-Reduction-Proxy' or 'Chrome-Compression-Proxy' here and in function names.

[bengr, 2014/02/07 23:55:36]

The version is the HTTP version from the origin, which could be 0.9, 1.0, or
1.1.

I agree about the names. The plan is to move to using 'ChromeProxy' in code, but
it will take a few CLs before that name is used everywhere.

[mef, 2014/02/12 18:12:18]

Are you sure? From this comment in rfc2616 it seems that it specifies the
protocol used to communicate with Chrome Proxy:

For example, a request message could be sent from an HTTP/1.0 user agent to an
internal proxy code-named "fred", which uses HTTP/1.1 to forward the request to
a public proxy at nowhere.com, which completes the request by forwarding it to
the origin server at www.ics.uci.edu. The request received by www.ics.uci.edu
would then have the following Via header field:

       Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

[bengr, 2014/02/12 21:14:00]

It is always the protocol used for the response from the upstream server. This
is what rfc2616 says:

The received-protocol indicates the protocol version of the message received by
the server or client along each segment of the request/response chain. The
received-protocol version is appended to the Via field value when the message is
forwarded so that information about the protocol capabilities of upstream
applications remains visible to all recipients.

On 2014/02/12 18:12:18, mef wrote:

+  size_t value_len = strlen(kDataReductionProxyViaValue);
   void* iter = NULL;
   std::string value;
-  while (headers->EnumerateHeader(&iter, "via", &value))
-    if (value == kChromeProxyViaValue) return true;
+
+  // Case-sensitive comparison. Assumes the received protocol and the space
+  // following it are always |kVersionSize| characters. E.g.,
+  // 'Via: 1.1 Chrome-Compression-Proxy'
+  while (response_headers->EnumerateHeader(&iter, "via", &value)) {
+    if (!value.compare(kVersionSize, value_len, kDataReductionProxyViaValue))
+      return true;
+  }
+
+  // TODO(bengr): Remove deprecated header value.
+  const char kDeprecatedDataReductionProxyViaValue[] =
+      "1.1 Chrome Compression Proxy";
+  iter = NULL;
+  while (response_headers->EnumerateHeader(&iter, "via", &value))
+    if (value == kDeprecatedDataReductionProxyViaValue) return true;
+
   return false;
 }