Pass the content size in the content-length header for file:// streams.

content/browser/loader/resource_dispatcher_host_impl.cc

Index: content/browser/loader/resource_dispatcher_host_impl.cc
diff --git a/content/browser/loader/resource_dispatcher_host_impl.cc b/content/browser/loader/resource_dispatcher_host_impl.cc
index d671e2b715abefdc166efd1417e480ffc84f137b..b864edc55f8ca8fb6169c83e4e4b0916bafc84c8 100644
--- a/content/browser/loader/resource_dispatcher_host_impl.cc
+++ b/content/browser/loader/resource_dispatcher_host_impl.cc
@@ -825,6 +825,11 @@ scoped_ptr<ResourceHandler> ResourceDispatcherHostImpl::MaybeInterceptAsStream(
   if (response->head.headers.get()) {
     stream_info->response_headers =
         new net::HttpResponseHeaders(response->head.headers->raw_headers());
+  } else if (stream_info->original_url.SchemeIsFile()) {
+    stream_info->response_headers = new net::HttpResponseHeaders(std::string());
+    stream_info->response_headers->AddHeader(
+        "content-length: " +
+        base::Int64ToString(response->head.content_length));

[mmenke, 2016/01/15 22:20:59]

The PDF viewer uses the content-length header to make some sort of caching
decisions?  That's not the actual length of the content after filtering.  I
suppose we don't really need to harden the PDF reader against this sort of thing
as an attack (Or against PDFs without content-lengths...), but it seems like
really flaky logic.

[mmenke, 2016/01/15 22:29:14]

If we go the bogus header route, wonder if we should add them for all file URLs.
 Looks like we do add bogus headers for blobs (Though, curiously, they don't
include the content length).

[Lei Zhang, 2016/01/15 23:13:29]

Sorry, I don't know anything about file URLS and "filtering", but at least in
the simple case of opening a PDF file from disk, this is the size of the file.

In terms of an attack, the PDF viewer already handles the case of not having a
content-length. I suppose sending a large content-length may cause extra memory
allocation in the PDF viewer.

[Lei Zhang, 2016/01/15 23:13:29]

I can't speak for other places. The StreamInfo is the data structure that gets
sent to the PDF viewer, so I can't think of another way to convey the file size
other than this or adding a new field to StreamInfo.

[mmenke, 2016/05/11 19:31:16]

My preference, from a correctness standpoint, would be to add a field to
StreamInfo - it seems more robust, and would also fix the case where
content-length is different from the uncompressed body length.  Adding this
header just for file URLs just for this API seems hackish to me, and misses some
more obscure cases (PDFs in data URLs, PDFs in blob URLs, PDFs in Chrome URLs
[If anyone does that], etc).

That having been said, I'm not sure how much of a pain passing this information
all the way down to pdf/document_loader.cc is.  I guess we'd have to update a
NaCl (ppapi?) interface to pass the information there as well?

   }
   delegate_->OnStreamCreated(request, std::move(stream_info));
   return std::move(handler);