Intent to ship: accept spaces and tabs in unquoted values (of e.g. "filename") used in Content-Disposition parameterized header pairs to to align with other browsers

141 views
Skip to first unread message

Gijs Kruitbosch

unread,
Aug 19, 2020, 12:52:45 PM8/19/20
to Anne van Kesteren
As of Firefox 81 I intend to update our parsing of Content-Disposition
headers so that spaces/tabs in unquoted values are treated as part of
the value (rather than as a separator, cutting off the value).

This is what Blink and Webkit already do.

Bug for this change: https://bugzilla.mozilla.org/show_bug.cgi?id=1440677 .

More context: the HTTP RFC spec for Content-Disposition (RFC6266) does
not allow parameter values to contain spaces unless the entire value is
quoted. However, a significant number of web services do not follow the
spec, and so we get a steady flow of bugreports that Firefox cuts off
the server-suggested `Some File.txt` filename into `Some`, while it
"just works" in other browsers.

This change will align our behaviour with what Blink and Webkit do. Anne
has filed https://github.com/httpwg/http-extensions/issues/1252 to
discuss what, if any, change we should make in the relevant
specification. Broadly, it seems developers working on browsers agree
that a header with such whitespace use is not valid given the spec, the
question is how to deal with that invalidity. Either way, necko's
pre-patch behaviour to cut off at whitespace is not likely to be
followed by other user agents given the consequences for users. In the
meantime, we felt we should at least remove the user-felt impact.

~ Gijs

Gijs Kruitbosch

unread,
Aug 19, 2020, 1:07:39 PM8/19/20
to
It's been pointed out to me that I neglected to merge the "intent to
prototype" requirements into my email. So:

Platform coverage: everywhere.
Preference: no pref.
DevTools bug: covered by existing network tooling (it already shows the
full header).
Other browsers: as noted, they already do this
web-platform-tests: TBC. We have internal tests which were updated, but
it doesn't appear WPT is set up to deal with this right now (by their
nature, "attachment" content doesn't load in-browser) as it'd need to
handle downloads and provide some way of asserting things about them.
This will likely be tackled after / as part of spec changes.

~ Gijs

Eric Rescorla

unread,
Aug 19, 2020, 1:30:15 PM8/19/20
to Gijs Kruitbosch, dev-platform
Ugh. This does seem like the right thing to do in a bad situation. Thanks
and thanks to Anne for working to get the spec updated.

-Ekr

On Wed, Aug 19, 2020 at 10:10 AM Gijs Kruitbosch <gijskru...@gmail.com>
wrote:
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Reply all
Reply to author
Forward
0 new messages