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

content/browser/loader/resource_dispatcher_host_impl.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.
 
 // See http://dev.chromium.org/developers/design-documents/multi-process-resource-loading
 
 #include "content/browser/loader/resource_dispatcher_host_impl.h"
 
 #include <stddef.h>
 #include <algorithm>
@@ skipping 807 matching lines @@
   scoped_ptr<StreamInfo> stream_info(new StreamInfo);
   stream_info->handle = handler->stream()->CreateHandle();
   stream_info->original_url = request->url();
   stream_info->mime_type = mime_type;
   // Make a copy of the response headers so it is safe to pass across threads;
   // the old handler (AsyncResourceHandler) may modify it in parallel via the
   // ResourceDispatcherHostDelegate.
   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);
 }
 
 ResourceDispatcherHostLoginDelegate*
 ResourceDispatcherHostImpl::CreateLoginDelegate(
     ResourceLoader* loader,
     net::AuthChallengeInfo* auth_info) {
   if (!delegate_)
@@ skipping 1711 matching lines @@
     load_flags |= net::LOAD_PREFETCH;
   }
 
   if (is_sync_load)
     load_flags |= net::LOAD_IGNORE_LIMITS;
 
   return load_flags;
 }
 
 }  // namespace content