W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: [#259] Handling invalid Content-Dispostion headers

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Sat, 06 Nov 2010 15:36:47 +0100
To: Maciej Stachowiak <mjs@apple.com>
Cc: httpbis Group <ietf-http-wg@w3.org>
Message-ID: <9mkad6luo3jqp5ekd82c09o4qs929pair2@hive.bjoern.hoehrmann.de>
* Maciej Stachowiak wrote:
>Now, at least a few browser implementors are trying to join the
>conversation and express our requirements. The topic of this particular
>thread is a fairly trivial request - an optional specification for error
>recovery when parsing the Content-Disposition header. Browser
>implementors like to agree on error recovery, because we find that in
>general it makes things better for our users. It seems like
>experimenting with this approach using an *optional* spec for *one*
>header field is a low-stakes experiment that won't hurt anyone who
>doesn't care to participate.

The Content-Disposition header is now 15 years old. There has never been
any confusion about how to handle backslash characters in quoted-strings
yet in those 15 years none of Microsoft, Mozilla, Apple, and Google have
bothered to handle them correctly, despite people filing bugs about that
years ago, https://bugs.webkit.org/show_bug.cgi?id=22381 for instance.

When Julian filed a bug for this in Chromium the implementer commented
on his tests saying they appear to be "tests for the sake of test rather
than solving real-life problems". That Apple does implment the RFC 2231
encoding has been https://bugs.webkit.org/show_bug.cgi?id=15287 known
for over three years, https://bugs.webkit.org/show_bug.cgi?id=20407 with
duplicate reports even. These are valid things, you need them in order
to suggest file names containing "special" characters, which actually is
an important feature.

We have been running an experiment, if you will, testing whether browser
implementors will implement the Content-Disposition consistently based
on a specification for fifteen years (and similar experiments are on-
going for any number of specifications, and the IETF httpstate working
group is about to launch another large scale experiment in this area).

So far nobody has volunteered to conduct the research required to come
up with a specification for error-tolerant Content-Disposition headers
where we could be reasonably sure that, in the unlikely event that the
browser implementers care to align their implementations with the spe-
cification, implementers will not run into compatibility problems that
they feel they need to handle in a manner contrary to the specification.

So we do not have the resources to conduct such an experiment, if we
did, it would be redundant with other experiments, and past experience
suggests we would not care much for the outcome. So I suggest we thank
the browser implementers telling us they like it when their code behaves
in a manner consistent with the code of their competitors; and revisit
this issue when browser implementers have shown through running code
that they not only like that, but actively invest resources into that,
something they haven't done much in the past couple of years as far as
the Content-Disposition header is concerned.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Saturday, 6 November 2010 14:37:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:32 GMT