Add support for fallback content for the frame. This includes main and subframes.

content/browser/loader/url_loader_request_handler.h

Index: content/browser/loader/url_loader_request_handler.h
diff --git a/content/browser/loader/url_loader_request_handler.h b/content/browser/loader/url_loader_request_handler.h
index fb0a1f4b2f31e521926888dc0f9ac9090e4e72a9..2bc22cac7ea67c0e484d5bb337516978acc3e748 100644
--- a/content/browser/loader/url_loader_request_handler.h
+++ b/content/browser/loader/url_loader_request_handler.h
@@ -10,6 +10,7 @@
 #include "base/macros.h"
 #include "content/public/common/url_loader.mojom.h"
 #include "content/public/common/url_loader_factory.mojom.h"
+#include "net/url_request/redirect_info.h"
 
 namespace content {
 
@@ -39,6 +40,26 @@ class CONTENT_EXPORT URLLoaderRequestHandler {
   // going forward. Subclasses who want to handle subresource requests etc may
   // want to override this to return a custom factory.
   virtual mojom::URLLoaderFactoryPtr MaybeCreateSubresourceFactory();
+
+  // Returns true if the handler delivers fallback content for the |response|
+  // passed. The |client| parameter points to the URLLoaderClient instance
+  // which is used for passing the fallback content and other information to
+  // the client. The |request| parameter points to the bound url request.
+  virtual bool MaybeGetFallbackForResponse(const ResourceResponseHead& response,
+                                           mojom::URLLoaderClientPtr* client,
+                                           mojom::URLLoaderRequest* request);

[kinuko, 2017/07/26 01:59:14]

(If we end up having this kind of hooks)

Could we try to make it look like a more generic response interception hook? 
I'd imagine something like:

void MaybeCreateLoader(...);
void MaybeCreateLoaderForResponse(...);

It also feels a bit unfortunate to need to pre-create ClientPtr and Request
pairs on every responses, could we avoid doing that?

[michaeln, 2017/07/26 23:08:41]

I don't know how much it helps, but we could expose the fallback handling with a
different API. The appcache system knows prior to returning from
MaybeCreateLoader() whether or not it has a fallback. There are three possible
return values from MaybeCreateLoader()
- a loader that loads the main resouce
- a loader that loads a fallback resource
- no loader

There's no case for the appcache providing a loader and a fallback_loader.

Here's a MaybeCreateLoaderCallback function signature that captures the
possiblities.

void MaybeCreateLoaderCallback(
    StartLoaderCallback start_it,
    ShouldFallbackForResponseFunction should_fallback_function);

bool ShouldFallbackForResponseFunction(response);

If |should_fallback_function| is not empty, that means |start_it| should only be
used for response fallback handling when should_fallback_function(response)
returns true.

The should_fallback conditions are pretty simple.
https://cs.chromium.org/chromium/src/content/browser/appcache/appcache_reques...

To simplify things, we could prohibit use of that api except for the appcache's
URLLoaderRequestHandler so the NavigationLoader would not have to deal with a
list of these potential fallbacks. It would need two new data members: a
should_fallback_function_ and a start_fallback_loader_function_.

Would that help? 

[ananta, 2017/07/27 02:40:25]

Removed the functions added to the URLLoaderRequestHandler interface. As per
michaeln's suggestion here and our discussion, passing a callback function in
the LoaderCallback
seems to be better. The LoaderCallback signature has been modified to take in an
additional callback function ResponseFallback which is passed in by AppCache if
it finds fallback for the main resource. This caused some changes to other
places which invoke the  LoaderCallback to pass in an empty ResponseFallback() 

[ananta, 2017/07/27 02:40:25]

We decided to go with the additional callback function parameter to
LoaderCallback here. This also ensures that we create the clientptr and request
only if we have a valid fallback

[kinuko, 2017/07/27 13:46:26]

Hm... sorry to say this, but I think I might have preferred the previous API,
which looked a little more straightforward and generic.  (Additional context: I
noticed there's another project, namely Web Packaging project, that might also
need response interception, and I'm trying to see if both can use common
mechanism.)

[jam, 2017/07/27 23:19:13]

If we don't want the appcache handler to make the network request and we have to
put something in URLLoaderRequestHandler, then either this patch or the latter
one is fine with me. I defer to others on which one is preferable. My main
motivation was to see if we can avoid adding anything to this interface, but
looks like that's not possible.

+
+  // Returns true if the handler delivers fallback content for the redirect
+  // |response| passed in. The |redirect_info| parameter contains the new
+  // location, etc. The |client| parameter points to the URLLoaderClient
+  // instance which is used for passing the fallback content and other
+  // information to the client. The |request| parameter points to the
+  // bound url request.
+  virtual bool MaybeGetFallbackForRedirect(
+      const ResourceResponseHead& response,
+      const net::RedirectInfo& redirect_info,
+      mojom::URLLoaderClientPtr* client,
+      mojom::URLLoaderRequest* request);
 };
 
 }  // namespace content