Obsolete
Status Update
No update yet.
Comments
kr...@chromium.org
[Empty comment from Monorail migration]
jk...@chromium.org
Hi krishnareddyperam, are you still having this issue in recent versions?
sh...@chromium.org
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.
For more details visit
da...@chromium.org
Closing this as won't fix as there hasn't been are response to the question in https://crbug.com/chromium/466965#c2 . Please reopen if this is still an issue.
li...@gmail.com
Still an issue on Chrome Version 68.0.3440.106 (Build officiel) (64 bits).
Content-disposition header is ignored, and instead Chrome uses some metadata from the PDF to generate the tab label.
I think content-disposition should take precedence if "filename" not empty.
Content-disposition header is ignored, and instead Chrome uses some metadata from the PDF to generate the tab label.
I think content-disposition should take precedence if "filename" not empty.
is...@google.com
This issue was migrated from crbug.com/chromium/466965?no_tracker_redirect=1
[Monorail components added to Component Tags custom field.]
[Monorail components added to Component Tags custom field.]
Description
Steps to reproduce the problem:
Request a pdf with
Content-Disposition as inline; filename="test.pdf"
and as Content-Type: application/pdf
With this request it is supposed to open the PDF in the browser.
I do have Adobe PDF Reader installed and made that as the default.
This same request displays correctly in the desktop chrome browser.
Request/Response headers are as follows:
Request
-------
GET /Mobilepdf/Mobile.cfm HTTP/1.1
Host:
Proxy-Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Linux; Android 4.2.2; HTC One Build/JDQ39) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.94 Mobile Safari/537.36
Referer:
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: JSESSIONID=C068982E6C1C0988BE79784E059B439D.cfusion
Response:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: no-cache, no-store, must-revalidate, max-age=0
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Disposition: inline; filename="test.pdf"
Content-Type: application/pdf
Date: Fri, 13 Mar 2015 11:03:42 GMT
Content-Length: 103778
What is the expected behavior?
When Content-Disposition is inline; filename="test.pdf"
and Content-Type is application/pdf, chrome should open the pdf in the browser itself rather than downloading it.
What went wrong?
PDF could't be viewed in browser.
Seems like content disposition type inline for PDf is not being honoured.
Did this work before? No
Chrome version: 28.0.1500.94 Channel: stable
OS Version: 4.2.2 htc one build JDQ39
Flash Version: Shockwave Flash 17.0 r0