Prerender: Confirm ServiceWorkers are invoked for NoState Prefetch

content/browser/service_worker/service_worker_context_request_handler.cc

 // Copyright 2014 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/service_worker/service_worker_context_request_handler.h"
 
 #include "base/time/time.h"
 #include "content/browser/service_worker/service_worker_context_core.h"
 #include "content/browser/service_worker/service_worker_provider_host.h"
 #include "content/browser/service_worker/service_worker_read_from_cache_job.h"
@@ skipping 37 matching lines @@
   // We only use the script cache for main script loading and
   // importScripts(), even if a cached script is xhr'd, we don't
   // retrieve it from the script cache.
   // TODO(michaeln): Get the desired behavior clarified in the spec,
   // and make tweak the behavior here to match.
   if (resource_type_ != RESOURCE_TYPE_SERVICE_WORKER &&
       resource_type_ != RESOURCE_TYPE_SCRIPT) {
     return NULL;
   }
 
+  // TODO(mattcary): still not clear if this is correct or not.
+  // Skip creation if job is prefetch.
+  if (request->load_flags() & net::LOAD_PREFETCH) {
+    return NULL;

[falken, 2016/12/27 01:27:00]

Returning null here just means that SW machinery will not intercept the request,
and it will go through the usual resource loading/network stack.

Also, ServiceWorkerContextRequestHandler is created for requests done from the
SW which means either:
- the SW calling fetch()
- the request for the SW script itself to start the SW

Since requests initiated by the SW calling fetch() are *not* intercepted by any
SW, they go straight to the normal network stack, hence the return null in line
55.

So ServiceWorkerContextRequestHandler only tries to intercept requests for the
SW script to start the worker. In this case, if we return null here, the SW
script load won't go through the expected path (which would reading or writing
to the SW script storage), and will instead go through the network stack. The
renderer will get the response for the script and start the worker anyway, which
is an unexpected case. In fact I expect this would cause a CHECK later when the
browser discovers a service worker is running without going through the expected
load path (I think the other null returns past line 55 also would cause this
CHECK, it's a long standing bug I'm trying to track down:
https://bugs.chromium.org/p/chromium/issues/detail?id=485900.

If the goal is to drop the job, I think we'd need to return a job that responds
to the request with an error, or cancel the request.

Also there is another request handler called
ServiceWorkerControlleeRequestHandler, which is for intercepting requests from a
"client" (typically a controlled page) that could be intercepted by the SW. I
suspect if you want requests involving NoPrefetch to not be intercepted by a SW,
you'll need code there too.

+  }
+
   if (ShouldAddToScriptCache(request->url())) {
     ServiceWorkerRegistration* registration =
         context_->GetLiveRegistration(version_->registration_id());
     DCHECK(registration);  // We're registering or updating so must be there.
 
     int64_t resource_id = context_->storage()->NewResourceId();
     if (resource_id == kInvalidServiceWorkerResourceId)
       return NULL;
 
     // Bypass the browser cache for initial installs and update
@@ skipping 51 matching lines @@
     int64_t* resource_id_out) {
   // We don't read from the script cache until the version is INSTALLED.
   if (version_->status() == ServiceWorkerVersion::NEW ||
       version_->status() == ServiceWorkerVersion::INSTALLING)
     return false;
   *resource_id_out = version_->script_cache_map()->LookupResourceId(url);
   return *resource_id_out != kInvalidServiceWorkerResourceId;
 }
 
 }  // namespace content