Also confirmed in : Version 67.0.3379.0 (Build officiel) canary (64 bits)
Confirmed on Mac OSX and Windows so far.

Actually seems to work fine with static pdf files, but not with a module serving the file. Here is the static file : https://www.pelicansport.com/media/amasty/amfile/attach/Manuel_Utilisateur_FR.pdf

I commented out the "Content-Length" header from the module serving the dynamic pdf and it works fine without it.

Is it possible to better handle the Content-Length in the Chrome PDF Viewer?

Seems like I'm not the only case, same thing using IIS10, only affecting Chrome : https://stackoverflow.com/questions/45246898/c-sharp-http2-download-failed-network-error

Taking a quick look - there's a DCHECK failure in PDFiumEngine::FinishLoadingDocument(). It's getting called even though doc_loader_->IsDocumentComplete() returns false.

And that's because, strangely, PDFiumEngine::OnDocumentCanceled() calls OnDocumentComplete() if at least some pages in the document got loaded. Maybe it should just fail rather than trying to display a partial document?

I haven't looked into what's going wrong in DocumentLoader/URLLoaderWrapperImpl.

I did notice this regressed. It used to work. Bisecting, we end up with https://chromium.googlesource.com/chromium/src/+log/db4f7fdb..a7ca6493, so it looks this is caused by r501344.

For some reason, the last chunk of data in the PDF isn't being saved by the DocumentLoader. As a result the rest of the PDF Viewer is confused.

I don't want to throw anyone in the wrong direction, but if the Content-Length is invalid, as pointed out by my colleague https://bugs.chromium.org/p/chromium/issues/detail?id=825829#c3, that might explain why the DocumentLoader doesn't read the last chunk.

The webserver is serving extra data in this case. When I fetch the URL with wget, it returns 934144 as the content length and a file of exactly that length.

When I fetch it with the PDF Viewer, the content length is still 934144, but the returned data has something extra tacked on:

<script type="text/javascript">window.location.href = 'https://www.pelicansport.com:443/pub/errors/report.php?id=1149244459128&skin=pelican';</script>

Looking around, I found [1].

elawrence: In the "overrun" case, is the modern browser behavior still to ignore the additional content?

[1] https://blogs.msdn.microsoft.com/ieinternals/2011/03/09/content-length-in-the-real-world/

On our side, we have found the module that is adding the extra content. Disabling this now makes the PDF file works fine in Chrome.

I still think that Chrome should be able to handle this scenario as Firefox and Edge seem to do it.

Let me know if you still need the server and the link to the broken PDF for your tests. Otherwise, I'll shutdown the server.

Thanks

I think I can fix the Chrome PDF Viewer without the test server.

RE #12: Yes, as of Chrome 67.0.3381.0 we continue to truncate downloaded files at the server-specified Content-Length. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/32094aacf709159a4535bcba0521fe58b125ce09

commit 32094aacf709159a4535bcba0521fe58b125ce09
Author: Lei Zhang <thestig@chromium.org>
Date: Wed Mar 28 18:29:15 2018

Ignore extra bytes in the PDF DocumentLoader.

In the overrun case, if the server specifies a given Content-Length in
the header and then sends more than the expected amount of data,
truncate the input at the expected size.

Also try to handle the underrun case by saving whatever pending data
can be saved.

BUG= 825829 

Change-Id: I0502ed14f9fa8c888030b89bb58c429f16f4540b
Reviewed-on: https://chromium-review.googlesource.com/984154
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546551}
[modify] https://crrev.com/32094aacf709159a4535bcba0521fe58b125ce09/pdf/document_loader.cc
[modify] https://crrev.com/32094aacf709159a4535bcba0521fe58b125ce09/pdf/document_loader.h

I would recommend spinning up the test server again and verify with 67.0.3383.0 or newer. (e.g. Canary channel later this week)

Able to reproduce the issue on chrome reported version 64.0.3282.186
Verified the fix on Mac 10.12.6, Windows-10 & Ubuntu 14.04 on Chrome version #67.0.3383.0 as per the comment#0
Attaching screen cast for reference.
Observed "Able to see full pdf file"
Hence, the fix is working as expected.
Adding the verified label.

Thanks!

Deleted: 825829.mp4 5.0 MB

	825829.mp4 5.0 MB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2cf20af4f35dfe9da1bf956d8bcc927e4d6f3473

commit 2cf20af4f35dfe9da1bf956d8bcc927e4d6f3473
Author: Artem Strygin <art-snake@yandex-team.ru>
Date: Thu Jun 14 14:26:53 2018

Fix download PDF document with server extra data.

In case of range request, if server send unexpectedly
extra data, ignore it.

BUG= 825829 

Steps to reproduce:
1) Clear browser cache.
2) Open PDF:
http://www.major-landrover.ru/upload/attachments/f/9/f96aab07dab04ae89c8a509ec1ef2b31.pdf#page=55
3) Wait until document finish loading

Expected:
 The loading of document is finished
Actual:
 Some times the loading of document is never finished.

Change-Id: I46fc8001bea5701e1e93d26d1ea6527d4736ff05
Reviewed-on: https://chromium-review.googlesource.com/1094634
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: Art Snake <art-snake@yandex-team.ru>
Cr-Commit-Position: refs/heads/master@{#567257}
[modify] https://crrev.com/2cf20af4f35dfe9da1bf956d8bcc927e4d6f3473/pdf/chunk_stream.h
[modify] https://crrev.com/2cf20af4f35dfe9da1bf956d8bcc927e4d6f3473/pdf/document_loader_impl.cc
[modify] https://crrev.com/2cf20af4f35dfe9da1bf956d8bcc927e4d6f3473/pdf/document_loader_impl_unittest.cc