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 
Content-Length).

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