Consistently use LoFi for an entire page

content/browser/loader/resource_loader.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 "content/browser/loader/resource_loader.h"
 
 #include "base/command_line.h"
 #include "base/location.h"
 #include "base/metrics/histogram.h"
 #include "base/profiler/scoped_tracker.h"
@@ skipping 84 matching lines @@
   request->GetMimeType(&response->head.mime_type);
   net::HttpResponseInfo response_info = request->response_info();
   response->head.was_fetched_via_spdy = response_info.was_fetched_via_spdy;
   response->head.was_npn_negotiated = response_info.was_npn_negotiated;
   response->head.npn_negotiated_protocol =
       response_info.npn_negotiated_protocol;
   response->head.connection_info = response_info.connection_info;
   response->head.was_fetched_via_proxy = request->was_fetched_via_proxy();
   response->head.proxy_server = response_info.proxy_server;
   response->head.socket_address = request->GetSocketAddress();
+  response->head.is_lofi = request->lofi_state() == net::LOFI_ON;

[davidben, 2015/08/27 18:53:50]

Without the embedder colluding, there's nothing ensuring that LOFI_DEFAULT is
handled correctly. If we're teaching //content about lofi state, //content
should be interpreting LOFI_DEFAULT. If it needs to call out to something to
query the bandwidth estimator, then //content can call out to its embedder via
one of the top-level client/delegate interfaces to control what LOFI_DEFAULT
means, with the default implementation being off.

(Was there an Intent to Implement for this header? We're adding a new header to
the web platform, so it needs to go through the Blink process.)

[bengr, 2015/08/27 21:14:07]

The header isn't really a header right now; it's a directive within the data
reduction proxy's "Chrome-Proxy" header. I.e., "Chrome-Proxy: q=low". I don't
think we want the web platform knowing about this. When we move to a separate
header 'RQ: low' we can remove the collusion. Is this ok with you?

[davidben, 2015/08/31 23:43:24]

Can we make it a separate header and do it properly? Otherwise this results in
an extremely weird API at the //content boundary. The API contract between
//content and its embedder is now "I set this lofi bit on every request, but
honestly I haven't the slightest clue what it means. I'll just propagate it.
There's also this LOFI_DEFAULT setting, but I don't know what to do with it
either. If you intercept the URLRequest and mutate it early enough, then I'll
read the value back and propagate as what you chose. Otherwise, uh, I'll make
something up."

[bengr, 2015/09/02 19:01:36]

I see. We might be open to making a server change to support 'RQ: low'. If we
can't, then for now we could possibly let the browser add q=low to the
Chrome-Proxy request header whenever it sees RQ: low. I'm a little hesitant,
though, to commit to using RQ, because the RFC is very much in flux, but agree
it is a better approach.

Megan, could you make the change to do it properly as per David's definition of
"properly?"  

[megjablon, 2015/09/02 21:25:41]

@David, I'm not sure I follow completely. I understand the issue with leaving
LOFI_DEFAULT uninterpreted, but you please explain how the separate header would
be properly used here? Where would we add 'RQ: low'? I'm trying to understand
the details of the design change you would like.

[davidben, 2015/09/04 14:41:22]

I don't think //content should manage state that it's clueless about. If it's to
collude with the consumer to interpret LOFI_DEFAULT, there should be a
//content-level hook for it.

I also think it makes more sense for //content to set the header, which is much
more easily done as a separate header. Although I care much more about the
uninterpreted LOFI_DEFAULT.

The separate header is much more important for caching. If your response depends
on a header, you MUST include it in Vary. I assume you don't want to stick
Chrome-Proxy into Vary since that'll affect everything.

My understanding from our discussions was that lofi mode was to be a straight-up
web platform feature (Blink process and everything) and a header that we simply
send and servers can implement if they wish. The DRP's role is instead just a
polyfill for sites that don't understand it.

This is much more forward-looking as Chrome is otherwise very consistently
pushing HTTPS and treating plain HTTP as deprecated.

[megjablon, 2015/09/15 00:14:33]

How will this work for the navigation? Since we make the decision to use LoFi on
a page on the network side, we have no way of knowing prior to that in //content
if we want to add the header or not.

   if (ServiceWorkerRequestHandler* handler =
           ServiceWorkerRequestHandler::GetHandler(request)) {
     handler->GetExtraResponseInfo(&response->head);
   }
   AppCacheInterceptor::GetExtraResponseInfo(
       request, &response->head.appcache_id,
       &response->head.appcache_manifest_url);
   if (info->is_load_timing_enabled())
     request->GetLoadTimingInfo(&response->head.load_timing);
 
@@ skipping 647 matching lines @@
       case net::URLRequestStatus::FAILED:
         status = STATUS_UNDEFINED;
         break;
     }
 
     UMA_HISTOGRAM_ENUMERATION("Net.Prefetch.Pattern", status, STATUS_MAX);
   }
 }
 
 }  // namespace content