Closed Bug 1440677 Opened 3 years ago Closed 6 months ago
.com - Problems with spaces in filenames (content-disposition not quoted)
Bug 1440677 - accept spaces and tabs in Content-Disposition header filename parameters because all the other browsers do, r?annevk!,valentin!
47 bytes, text/x-phabricator-request
|Details | Review|
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0 Build ID: 20180206200532 Steps to reproduce: Access https://fathomless-shelf-94559.herokuapp.com/ Actual results: Download the file with filename `Junk` Expected results: The file name should be `Junk Text.txt`
This error occur when the filename parameter contains space. Other browser such as Chrome, Edge, Vivaldi doesn't have this parsing problem.
NI :bz because bug 221028 is now in Core Graveyard, so it doesn't seem right to dupe this to it.
Has Regression Range: --- → irrelevant
Has STR: --- → yes
Component: Untriaged → File Handling
OS: Unspecified → All
Hardware: Unspecified → All
Summary: content-disposition parsing error → herokuapp.com - Problems with spaces in filenames (content-disposition not quoted)
It's still the right place; I have no idea why someone stuck it in "graveyard".
Note that if there were a clear spec for how to support space here we could consider switching to it. But right now, the only spec for this stuff explicitly days spaces are only allowed inside a quoted string.
For connivance to other users, why stuck with spec while other vendors provide the functionality? I understand the importance of following spec. However, it will just drive end user crazy then switch to others. I think user experience take more place in this case than following spec.
Last I checked, there were cases in which the other browsers have incorrect behavior when the server is doing the right thing, as a result of them wanting to support this spec deviation... Again, if there is a behavior that does _not_ have that problem and is clearly described switching to it would not be a problem. But fixing up this sort of server error at the expense of breaking other things is not necessarily a great tradeoff.
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #3) > It's still the right place; I have no idea why someone stuck it in > "graveyard". The entirety of Core :: File Handling was moved to Core Graveyard :: File Handling. So bug 221028 and its myriad of dupes ended up there. Your previous decision is at bug 221028, comment 7 and your explanation at bug 221028, comment 88.
Anne, has this come up in the fetch/etc work?
No, I actually thought Julian had solved Content-Disposition by creating rather exhaustive tests for it, but I guess other browsers didn't bother to fix their bugs?
Flags: needinfo?(annevk) → needinfo?(julian.reschke)
Looking at comment 7 I suspect Julian wouldn't disagree with Julian from 6 years ago, but if other browsers are forcing our hand here, it might be time to reconsider? It does seem like there's a huge number of duplicates for this bug...
My position on this hasn't changed. Get servers to send valid header fields instead of competing on lazy parsing. If a sender doesn't quote whitespace, it'll likely make other mistakes, such as handling non-ASCII incorrectly, or including other disallowed ASCII characters.
So how will Firefox dev team handle this? Fix it or following the standard?
I think that to "fix it" there needs to be a specific behavior proposed. Then we can at least evaluate whether that behavior is reasonable... Ideally all browsers would implement the same behavior here, obviously.
Then obviously Firefox behavior of handling spaces in Content-Disposition is not equal to other majority of browsers such as Chrome.
I have no idea what comment 14 is trying to say, for what that's worth.
I'm trying to respond comment 13, where you said (In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #13) > Ideally all browsers would implement the same behavior here, obviously. Firefox don't do the same as other browsers like Chrome if there were spaces in Content-Disposition header.
In addition to comment 16, should the dev team make Firefox behave like other browsers?
Probably yes, if the other browsers actually agree on all the edge cases (last I checked they didn't) and if there is a clear description of how they behave, instead of us implementing something that doesn't match them anyway. That's what I've said repeatedly in this issue.
Component: File Handling → Networking
Priority: P3 → --
Product: Firefox → Core
Priority: -- → P2
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Attachment #9170115 - Attachment description: Bug 1440677 - accept spaces in Content-Disposition header filename parameters because all the other browsers do, r?annevk!,valentin! → Bug 1440677 - accept spaces and tabs in Content-Disposition header filename parameters because all the other browsers do, r?annevk!,valentin!
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/d1f68e042451 accept spaces and tabs in Content-Disposition header filename parameters because all the other browsers do, r=annevk,valentin,necko-reviewers
You need to log in before you can comment on or make changes to this bug.