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

On 04.11.2010 03:42, Mark Nottingham wrote:
> In looking at Adam's feedback and the resulting discussion, I'm considering whether we should try to define an OPTIONAL error-handling profile that defines a method of handling invalid Content-Disposition field-values.
> E.g., this could be an appendix to the specification that lists a set of behaviours, such as:
>    - when there are multiple parameters with the same value, choose the first one
>    - when there are characters that aren't allowed in the BNF, transform them to...
>    - etc.
> that implementers could follow if they wish to. Other specifications could, at their option, require conformance to such a profile.
> By necessity, such a thing would not duplicate requirements from the authoritative text, would not override those requirements, and it would not provide alternate algorithms.
> To help figure out if this is a productive way to go, I'd like to hear:
>   a) thoughts from folks about this approach, and
>   b) some indication of who'd be willing to contribute text and/or time for testing, and
>   c) expressions of interest from implementers in such an optional profile (i.e., an indication that it's something they'd find useful).
> </chair hat>

I believe it would be a waste of energy to specify a specific strategy 
*unless* we have evidence that it's needed in practice. For this 
particular case (Content-Disposition in HTTP) I added several tests for 
invalid headers just to observe whether implementations agree on what to 
do, and in most cases they do not.

In addition, micro-managing this may even be harmful if we end up 
defining different strategies for different headers (for instance for 
Content-Type as compared to Content-Disposition). It seems it would be a 
better use of our time to work on test cases, identify common syntax 
patterns, and help UAs to get their code fixed.

That being said: a potential security risk changes things (see 

Finally, I'm not opposed to people working on things like Informational 
RFCs on this topic, but we should be careful that these documents then 
really represent cross-UA agreement, and not just what somebody learned 
from several browser's source code. (For instance, HTML5 has 
requirements on Content-Type parsing that disagree with what IE does, 
but the spec claims it's needed for "compatibility with existing content").

Best regards, Julian

Received on Thursday, 4 November 2010 15:17:40 UTC