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

* Mark Nottingham wrote:
>To help figure out if this is a productive way to go, I'd like to hear:
> a) thoughts from folks about this approach,

Well, to offer a very simple perspective on this, and to pick just some
random examples, several years ago I had to use a web service where I'd
to upload a file, make changes to the file locally and upload it again.
The browser I was using allowed re-uploading the file using "reload",
but when the file size changed it specified the old size of the file,
and sent the new content. That's a clear violation of the HTTP standard,
there is no need to conduct research on the real-world impact of fixing
the bug, there should be nothing remotely difficult about fixing it,
this is an actual end-user affecting bug, one where a user bothered to
both file a bug about it and talk to staff of said vendor about it, and
several years later that bug is still not fixed.

As another example, I was experimenting with fully conforming but some-
what long domain name labels. One browser exhibited utterly strange be-
havior, it truncated the label according to non-obvious rules. This may
have security implications, is a clear violation of the specifications
in question, fixing it has zero compatibility impact, it's a real-world
problem considering that long domain names aren't that uncommon, it was
reported, and several years later the problem is still not fixed.

What we have here with the Content-Disposition header, well, there is
zero confusion about how to handle escapes in quoted strings, there are
test cases, bugs filed for in some cases a long time, affected browser
vendors have yet to fix their code. Similarily, while there may have
been confusion about the somewhat arcane escaping syntax implemented by
some, that browsers differ in which syntax they support has been known
for quite some time, again there are test cases and bugs and so on, the
ability to specify non-ascii filenames reliably is actually in important
feature, yet browser developers aren't exactly jumping on the chances to
address this problem.

And I could go on with any number of browser bugs that have been known
for years, that do not require research into how compatiblity with ex-
isting content may be impacted, do not require forming consensus around
some issue, do not require writing specification text, that clearly do
affect real-world use cases, that are not being fixed, apparently for a
lack of botherones and round-tuits.

We have problems suggesting file names with non-ascii characters for
HTTP resources. The draft attempts to address that, by specifing a
profile that already works across a number of implementations, so that
the other implementations can catch up and so that people wishing to
suggest such file names have a reference on how to do that. It does
that reasonably well, and there is reason to believe that the profile
will actually be implemented where it isn't already.

There is no reason to believe that browser vendors will invest rather
significant resources to come up with a specification and a test suite
and making sure the specification gets implemented in their products
only to make their implementations behave more alike. This is low-level
parsing code, which is where the next unanticipated compatibility pro-
blem and the next security advisory lie. Much less is there evidence
that non-browser implementations will follow suit. And most certainly
there are more cost-effective things browser vendors could invest in.

Any effort that will be spent on specifying how to handle malformed
Content-Disposition headers will without a doubt negatively affect
what effort is spent on fixing other bugs, implementing new features,
creating test suites, and so on. The moment, say, Maciej says Apple
is committed to spend $10,000 USD in engineering resources on this, I
will be all supportive. Until then I will consider anyone arguing we
should specify how to handle content that does not exist, for all
that I can tell, a candidate for an "Enemy of Interoperability" award.

An even simpler perspective is this:

  Don't start a business if you can't explain what pain it solves,
  for whom, and why your product will eliminate this pain, and how
  the customer will pay to solve this pain. -- Joel Spolsky.

Here there is no evidence of an actual pain, there is no evidence
that there is anything we could reasonably do to eliminate it, and
much less evidence that anyone would actually pay to have it solved.
I can understand that this discussion makes sense from an engineering
perspective, but it does not make sense from a business perspective.
-- 
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 Friday, 5 November 2010 01:33:32 UTC