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

My personal .05:

On 07/11/2010, at 3:22 AM, Julian Reschke wrote:

> On 04.11.2010 20:45, Adam Barth wrote:
>> ...
>> That seems unlikely to be deployable.  What's more likely is that the
>> new-and-improved consistent behavior will be permissive rather than
>> draconian.  For example, in the multiple disposition-type case, we'd
>> take the first disposition-type (or whatever) rather than ignoring the
>> header field entirely.
>> ...
> Making IE non-compliant (or even more-compliant than before).

How so? If it's an optional error-handling profile, whether they implement it or not doesn't affect conformance to Content-Disposition. It's true that they won't conform to the error handling profile, but I'd hope that the folks coming up with that profile would do everything they can to make it at least mostly backwards-compaitlbe with IE.

> I'll say it again: there are many things that can be done to improve things (for the whole HTTP space):
> - clarify the spec for conforming headers, add examples
> - write test cases
> - identity bugs, lobby for fixing and/or supply patches
> - identify common header micro syntaxes
> - write reference implementations for the above
> - encourage re-use of those patterns
> - think about standardizing error recovery (or rule it out)
> The last point in *my* point of view has the lowest priority, in particular as long as the implementations do not even treat *valid* header field values correctly.

I agree that there are many things that we need to do, and that the valid cases are the low-hanging fruit. Based on recent bug traffic I've seen, it appears that the browser vendors *are* paying attention to it. 

That doesn't mean we can't do the last point, however, if we have the attention of the right people, as well as the appropriate resources. 

> Claiming we need to do all of this at the same time isn't constructive as long as the pool of people doing actual work doesn't grow.

Agreed. We cannot and <chair hat>will not</chair hat> do this work without the involvement of browser folks. 

Mark Nottingham

Received on Saturday, 6 November 2010 23:02:36 UTC