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

On Sat, Nov 6, 2010 at 9: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).
> Can you remind me what the gain is?

The gain is that in the future user agent implements can read this
document and converge their behavior be the same.  Writing down
desirable, implementable error handling leads to interoperability.

> Do you have data on content of this type relying on one specific behavior?

That's not relevant to this discussion.  We're focused on the future.
Existing content is a constraint on what type of error handling is
implementable, not one whether we should recommend a specific way of
handling errors.

> I'll say it again: there are many things that can be done to improve things
> (for the whole HTTP space):

I'd encourage folks who are interested in doing those things to do those things.


> - 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 think this discussion is evidence that different folks in this
working group have different priorities.  In particular, my point of
view is that defining precise error handling semantics is quite

> 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.

We have many problems in life, but a lack of engineering resources
isn't one of them, thankfully.


Received on Saturday, 6 November 2010 21:22:47 UTC