http-extensions
http-extensions copied to clipboard
httpwg
Content-Disposition: whitespace in filename parameter without quotes
Firefox is feeling forced to support whitespace without quotes in the filename parameter of the Content-Disposition header. See https://bugzilla.mozilla.org/show_bug.cgi?id=1440677.
In https://bugs.chromium.org/p/chromium/issues/detail?id=1006345 @MattMenke2 suggests removing whitespace without quotes support is not worth it to Chrome.
I haven't surveyed other clients, but it seems pretty clear what servers are doing (perhaps not in detail, but they're emitting whitespace without quotes).
I haven't surveyed other clients, but it seems pretty clear what servers are doing (perhaps not in detail, but they're emitting whitespace without quotes).
My assumption is that they just string-concat filenames without any care; the problem just happens to surface with whitespace most of the time. I'm pretty sure that servers that send unquoted whitespace also have trouble with non-ASCII characters, or with other ASCII characters not allowed in tokens (such as "(" and ")").
Note that truncating at whitespace can change file extensions, which can have security implications. So if we want to reach consensus on doing something other than what Chrome does here, I don't think we want to do what FireFox does.
Truncating isn't a good idea, indeed. The "proper" approach would be to ignore the filename information, as the parameter does not parse as spec'd.
The entire header doesn't parse as specced, though, not just some subset of it. Of course, just ignoring the header results in other potential security issues. Ideally, we'd just reject responses with invalid headers, but that would likely result in way too much breakage for anyone to ship.
Even just ignoring the filename will likely result in widespread breakage. Not sure if there'll be the willingness to go through that, on the Chrome side of things.
The entire header doesn't parse as specced, though, not just some subset of it.
That's the pedantic point of view (which I happen to like). But one could argue that failure to parse parameters does not require to throw away the disposition type.
That's the pedantic point of view (which I happen to like). But one could argue that failure to parse parameters does not require to throw away the disposition type.
But that necessarily require us to at least partially parse the invalid content, so we then actually need to specify how and when invalid parts of a header should be parsed.