URL ending with .pdf causes Brave to ignore Content-Type, then fail because document is not PDF #10554
Comments
bsclifton
added
needs-investigation
|
This happens a lot for me in github when opening PDFs, because the URL contains the filename. |
|
I have this issue frequently, using Brave on both Linux (Ubuntu Mate) and Windows 10. It's happened through several versions of Brave, I'm currently using 0.19.105. I use a lot of these URLs while transcribing files on Wikisource. I find that I DO have the problem if I control-click a link that ends in .pdf (to open the link in a new tab). I also DO have the problem if I paste the URL ending in .pdf in the address bar manually. But I DO NOT have the problem if I simply click the link. To reproduce, visit the following page, and then try clicking the "Source" tab near the top of the page, using both methods described above: https://en.wikisource.org/wiki/Oregon_Historical_Quarterly/Volume_7/The_First_Fruits_of_the_Land_(Part_1) |
|
See my comment in #12008 (comment) |
|
Since #12008 got closed, I'll move my research notes here. The problem is in the PDF check in /**
* Converts a potential PDF URL to the PDFJS URL.
* XXX: This only looks at the URL file extension, not MIME types.
* @param {string} url
* @return {string}
*/
toPDFJSLocation: function (url) {
if (url && UrlUtil.isHttpOrHttps(url) && UrlUtil.isFileType(url, 'pdf')) {
return UrlUtil.getPDFViewerUrl(url)
}
return url
}, |
|
Not sure if this is related or helpful, but the following Dropbox shared PDF (https://www.dropbox.com/s/z4oarzyiqeci8df/API%20Landscape%20V2_March%202017.pdf?dl=0) renders fine when accessed via a link, but when pasted directly, I get the following error: Invalid or corrupted PDF file. |
|
Yeah, this is exactly the problem: |
…sponse headers.
…sponse headers.
bsclifton
modified the milestones:
0.24.x (Developer Channel),
0.23.x Release 4 w/ Chromium 68 (BETA Channel)
bsclifton
added
QA/test-plan-specified
and removed
needs-investigation
|
There is another issue here beyond what what fixed. here's another failure to open. If there's an existing bug report, let me know chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/https://onlinelibrary.wiley.com/doi/pdf/10.1111/cdev.12853 |
|
I can't get at that link due to Wiley's paywall. I'm not sure it's a PDF issue, but perhaps redirects on their side related to whether or not you can read it? |
|
It opens fine on safari, and the URL shown at Wiley is to the PDF for me. |
|
Another that fails pasted below (will also be paywalled).
I think the issue is that the server exposes a url that doesn't end in pdf. Safari handles these OK (i.e., the pdf renders fine and can be printed). Interestingly, Safari displays the chrome for downlaod an dopen in preview, but these don't work. Also right-click "open in Preview" fails in safari. chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/https://uoe.sharepoint.com/sites/hss/ppls/PPLS%20Document%20Library/Research/Research%20Leave/ResearchLeavePolicyand%20Form%202019-2020.pdf?utm_campaign=2200746_PPLS%20Weekly%20Digest%20Test%2003.10.18&utm_medium=email&utm_source=College%20of%20Arts%2C%20Humanities%20%26%20Social%20Sciences%2C%20The%20University%20of%20Edinburgh&dm_i=2MQP,1B63U,7JASRD,48SQJ,1 |
|
Are you able to see (and report here) the headers you get when that request is made? |
|
The source? here you go: https://www.dropbox.com/s/wo41hxy14c6mgoz/source%20for%20beta.html?dl=0 |
|
I meant the headers sent with that URL. Whether or not PDF.js tries to render a URL depends on the headers sent along with the content. In the screenshot above, it is PDF.js that is reporting the failure, likely because it's getting HTML instead of a PDF; but I'm curious why it thinks it's a PDF (i.e., are the headers such as |
|
thanks, you'd have to give me a how-to for me to capture headers. |
|
If you open the developertools (in brave go on a website and right click somewhere and click inspect element). Then go to network and reload the website. Then you get for each request the headers as you can see in the following picture |
|
cmd-option-I doesn't work, and right-click: inspect is grayed out (I guess the pdf viewer doesn't look like an element) |
|
You can open the developer console before you access the content. Then all following network traffic gets logged you have then just to find the right entry. |
|
unfortunately, as soon as the viewer widget loads, it closes the developer console... |
|
Candidates have hex names in the names panel, three ending in .SVG one in .woff2, and one with a massive name beginning data:application/font-woff;… Could be: General OR OR OR General |
Test plan
Open the following links in a new tab and ensure they load without any issues:
Original issue description
Did you search for similar issues before submitting this one?
Yes.
Describe the issue you encountered:
Feel free to rename the title. :)
From community https://community.brave.com/t/url-ending-with-pdf-causes-brave-to-ignore-content-type-then-fail-because-document-is-not-pdf/6055?u=eljuno
Platform (Win7, 8, 10? macOS? Linux distro?):
macOS
Brave Version (revision SHA):
0.18.14
Steps to reproduce:
1.
2.
3.
Actual result:
Expected result:
Brave fail to load the URL
Will the steps above reproduce in a fresh profile? If not what other info can be added?
Is this an issue in the currently released version?
Can this issue be consistently reproduced?
Extra QA steps:
1.
2.
3.
Screenshot if needed:
Any related issues:
The text was updated successfully, but these errors were encountered: