Content-Disposition: inline filename is ignored on non-2xx status codes
Reported by
b...@bui.pm,
May 2 2016
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36 Example URL: https://yiff.party/ Steps to reproduce the problem: 1. Have a webpage that returns the "inline" disposition type along with a non-2xx status code In the example provided, this Content-Disposition header is returned: Content-Disposition: inline; filename="sadnate.jpg" 2. Attempt to save the file 3. The dialog does not show the correct filename What is the expected behavior? The save dialog should offer to save the file with the default filename as set in the Content-Disposition header. What went wrong? The save dialog offers the filename "download" if the file is the root document, otherwise the last part of the path. Did this work before? N/A Chrome version: 50.0.2661.94 Channel: stable OS Version: Flash Version: Shockwave Flash 21.0 r0 The feature works on Firefox, and there is nothing in RFC 6266 that indicates a non-successful status code should cause the header to be ignored, so I have to assume this is a bug. I am also assuming that the bug occurs with all non-2xx status codes as I've only tested it with 401.
,
May 4 2016
,
Dec 8 2016
,
Dec 11 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 18 2018
,
Mar 23 2018
Ping. I have the same issue. Is there any workaround? I can't build a working website for Chrome. Version 65.0.3325.181 (Official Build) (64-bit) Linux Firefox handles this fine.
,
Mar 23 2018
Hi, dvyukov@, do you have any URL to test with?
,
Mar 23 2018
I'd say simple work around is to return HTTP 200. inline should work in that case.
,
Mar 24 2018
This is broken even with 200. Here is repro URL: https://syzkaller.appspot.com/text?tag=ReproC&id=5837837853261824 It is served with 200 and: content-disposition: inline; filename=repro.c but when I press ctrl+s, chrome saves to text.txt.
,
Mar 24 2018
Maybe it's related to the Content-Type? Intended filename: https://httpbin.org/response-headers?content-disposition=inline;%20filename=custom-filename&Content-Type=application/json Wrong filename: https://httpbin.org/response-headers?content-disposition=inline;%20filename=custom-filename&Content-Type=text/plain
,
Mar 25 2018
I've tried to put file name into url as a workaround: https://syzkaller.appspot.com/x/repro.c?id=5150723616538624 but not luck, chrome still saves this as "repro.txt". .txt is not the only extension used for plain text content. c/patch/diff/log are all perfectly valid extensions for plain/text.
,
Mar 26 2018
Thanks for providing the URL.
,
Mar 26 2018
Hi, dvyukov@, this is save page feature, it doesn't use the download code path. I guess the content-disposition header is not propagated. Add Blink >SavePage for triage.
,
Mar 29 2018
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by maksim.s...@intel.com
, May 3 2016