repeated filename parameters, Re: Working Group Last Call: draft-ietf-httpbis-content-disp-02

[Julian Reschke <[e-mail]>]

On 02.10.2010 18:16, Adam Barth wrote:
> This document appears to be insufficiently precise for user agents to
> implement Content-Disposition.  In particular, it does not
> disambiguate what filename a user agent should use if multiple
> filename attributes are present....

Repeating a parameter makes the header instance invalid, this should be 
pointed out; I opened 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/244> to track this 
(and also added a test case at 
<http://greenbytes.de/tech/tc2231/#attwith2filenames>).

> ... The grammar will fail to parse a
> large number of Content-Disposition headers user agents receive on the
> public Internet, etc....

That's not a problem. There are no specific requirements on handling 
malformed headers, just like with any other HTTP header field, unless it 
affects security.

> ...  The document says:
>
> [[
>     Based on interoperability
>     testing with existing User Agents, it fully defines a profile of the
>     features defined in the Multipurpose Internet Mail Extensions (MIME)
>     variant ([RFC2183]) of the header field
> ]]
>
> We should either add enough detail to the document to allow for user
> agent implementations or clarify that this document is intended to
> apply only to servers.  For example, we could change the above
> paragraph to the following:
>
> [[
>     Based on interoperability testing with existing User Agents, it
> defines a profile
>     for use by HTTP servers of the
>     features defined in the Multipurpose Internet Mail Extensions (MIME)
>     variant ([RFC2183]) of the header field
> ]]
> ...

I don't understand the distinction between user agent and server here.

We are defining a response header field. The producer sets it, 
expressing additional instructions on how to handle the payload. The 
recipient can follow it or ignore it. For instance, a UA on a mobile 
phone without filesystem will likely ignore the "attachment" disposition.

For invalid header field instances, there aren't any specific 
requirements. Do you have any evidence these are required?

Best regards, Julian