Issue metadata
Sign in to add a comment
|
Corrupt file download if service worker is running
Reported by
jfranken...@gmail.com,
Dec 27
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Steps to reproduce the problem: 1. Run an Angular Web App with active service workers 2. Disable caching for REST-API URLs 3. Try to download a file from Backend via GET request What is the expected behavior? Complete file is downloaded correctly. What went wrong? File download seems to be complete, but the downloaded file is corrupt. E.g. after downloading a PDF that is actually 539kb large, we get files of different sizes, 504kb, 508kb, 516kb, ... Content-Length attribute in the response is always set correctly. If we unregister the service worker right before the download, we always get a complete file. Find the service worker config attached. The GET URL for the file download is matched by the pattern "/api/**". Did this work before? Yes <71 Does this work in other browsers? Yes Chrome version: 71.0.3578.98 Channel: stable OS Version: OS X 10.14.2 Flash Version: https://www.chromestatus.com/feature/5712608971718656 maybe related to Background Fetch API? Can be reproduced also on Windows.
,
Dec 27
,
Dec 27
Unfortunately, I cannot share the site since it is an internal application with restricted access. I tested with the flags you mentioned and I can provide the following feedback: if both flags are DISABLED the problem cannot be reproduced any longer, as soon as at least one of them is ENABLED, the problem occurs. Then, the first download is always successful, if the file is downloaded again afterwards, the file is corrupted in about 9 of 10 cases.
,
Dec 27
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 27
,
Dec 27
,
Dec 28
Looks like a regression with ServiceWorkerServicification, could be the same as issue 916514 . Have you seen this with files other than PDFs?
,
Dec 28
,
Dec 28
Yes, this also happens with .xlsx and .pptx (this are the file types we do support. I.e. it happens with all file types that are supported in our application context).
,
Dec 28
It seems that corrupt files are simply "cut off" at the end, i.e. as if not the complete byte stream is read during the download, although the Content-Length response header indicates the correct length of the byte stream. Find attached a correct file (Dokument1.pdf, 376kb) and a corrupt file (Dokument1 (1).pdf, 340kb).
,
Dec 28
As per comment# 3 from reporter, it isn't possible to provide sample Test file/URL that reproduces the issue, without sample file TE cannot proceed further on triaging the issue. Hence removing Needs -Bisect Label .
,
Jan 4
I think this is affecting PDF download on our site also using service worker where I am happy to share examples as it's all public domain. If you register the service worker on https://www.barnsley.gov.uk, any PDF download for example the following fails to render in Chrome 71. https://www.barnsley.gov.uk/documents/bin%20calendars/Week%204%20Day%205.pdf This did work before 71, hopefully this is related / useful to diagnosis.
,
Jan 4
Bug 918944 has an identical report, but it also has a reproducible test case. I'm duping over to that bug. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by shimazu@chromium.org
, Dec 27