MHTML: Allows 'data:' URLs to be processed using normal request processing.

third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp

Index: third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp
diff --git a/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp b/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp
index 471f98fae3e9992d44a7f91549ee9d60213933c6..3080598fcc67b0367c1d2578aaef0145dbddde55 100644
--- a/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp
+++ b/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp
@@ -442,12 +442,16 @@ Resource* ResourceFetcher::requestResource(FetchRequest& request, const Resource
         }
     }
 
-    bool isStaticData = request.resourceRequest().url().protocolIsData() || substituteData.isValid() || m_archive;
+    bool isDataUrl = request.resourceRequest().url().protocolIsData();
+    bool isStaticData = isDataUrl || substituteData.isValid() || m_archive;
     Resource* resource(nullptr);
     if (isStaticData) {
         resource = resourceForStaticData(request, factory, substituteData);
-        // Abort the request if the archive doesn't contain the resource.
-        if (!resource && m_archive)
+        // Abort the request if the archive doesn't contain the resource, except

[Dmitry Titov, 2016/09/19 19:54:16]

I still feel the resourceForStaticData should succeed in this case. I think not
loading fonts before they are used is stemming from the desire to avoid actual
network load of large fornts that are mentioned by URL in the stylesheet. There
are stylesheets out there that are listing a bunch of font resources by URL but
the page ends up using one or none etc. In those scenarios, we should avoid
loading. 

As for fonts present in archive as data: URLs, they are already here and it
doesn't make much sense to differentiate them from say images in the same
archive.

Lets discuss a bit offline, perhaps I'm missing something.

[dewittj, 2016/09/20 22:44:55]

The CSS spec says that fonts should not be "downloaded" unless referenced:
https://www.w3.org/TR/css-fonts-3/#font-face-loading

Chrome seems to interpret that as not processing the font - no exceptions etc -
until the font is referenced.  There is a test that checks this behavior for
fonts specified as data: URLs.

It would be better if resourceForStaticData could return a resource that'd
finish loading asynchronously.  Today it calls finish() directly, which is what
triggers the console exception.

I believe that if we just fall through to createResourceForLoading, we will use
the net stack to decode and finish the font resource loading, which implies the
desired async behavior.

+japhet - do you have an opinion on how we should enforce font async loading,
while being certain that archives never can access the actual network?

[Nate Chapin, 2016/09/21 19:30:02]

What if resourceForStaticData() checks resourceNeedsLoad(), and if it returns
false, creates the Resource* but doesn't initialize it? I don't know if that
will catch any cases besides data: urls, but assuming it was data: urls only,
then you could just have startLoad() check whether this is a data: url and do
the parse. That requires refactoring resourceForStaticData() a bunch, though, as
you'd need to pull populating the Resource into a helper.

Having written this idea out, I'm not skeptical that it's cleaner than what you
have here.

+        // in the case of data URLs which might have resources such as fonts
+        // that need to be decoded only on demand.  These data URLs are allowed
+        // to be processed using the normal ResourceFetcher machinery.
+        if (!resource && !isDataUrl && m_archive)
             return nullptr;
     }
     if (!resource)