Re: Content-Disposition cardinality / priority [was: TICKET 259: 'treat as invalid' not defined]

On 03.02.2011 05:30, Mark Nottingham wrote:
>
> On 12/12/2010, at 6:42 AM, Adam Barth wrote:
>>>
>>>    If the field value does not conform to the grammar (such as when not
>>>    exactly one disposition type is specified), ignore the whole header
>>>    field.
>>
>> This doesn't cover cases like the following:
>>
>> Content-Disposition: attachment; inline; filename=foo.exe
>>
>> We want to treat those as an attachment.  Another grammer we could use
>> might be the following:
>>
>>      field-value = item *( ";" item )
>>      item          = disp-type / param
>>      disp-type   =<OCTET, except ";" and "=">
>>      param       = param-name "=" param-value
>>      param-name =<OCTET, except "=">
>>      param-value =<OCTET, except ";">
>>
>> We could then say that first disp-type and the first param are the
>> ones that matter.  (I'm not sure this grammar handles<">  correctly,
>> but I'm sure we can sort that out.)
>
> As discussed earlier, that seems like pretty common behaviour:
>    http://greenbytes.de/tech/tc2231/#attandinline

Actually, *that* test doesn't provide any insight as most UAs *appear* 
to ignore the header field.

The next one, <http://greenbytes.de/tech/tc2231/#attandinline2>, 
reverses the disposition types, and is a bit more interesting.

Taken together, they show that most UAs take the first type, while IE 
takes the second.

To me this indicates that we don't have any interop here, and that it's 
unlikely that treating this as invalid would actually break existing 
content.

> ... although I'm not sure about the BNF change.
>
> What about loosening the definition of disposition-parm to make the '=' optional, so that anything after the first will be treated as a parameter (and therefore ignored)? Just thinking out loud.

There's some precedence here, RFC 5988 does exactly that (allowing 
value-less extension parameters, same in RFC 2068).

I'm not thrilled about that, and I note that this make this spec 
incompatible with Content-Disposition in MIME, which I was trying to avoid.

Are we discussing the Adam's "error-friendly" BNF, or the normative one?

>>> D.3.  Checking Cardinality Constraints
>>>
>>>    If the parameter sequence contains multiple instances of the same
>>>    parameter name, ignore the whole header field.
>>
>> We'd prefer to use the first one rather than ignore the header field.
>
> That seems like pretty common behaviour:
>    http://greenbytes.de/tech/tc2231/#attwith2filenames

That may be true, but it doesn't give us any information about how 
frequently it's used. Which brings us back to the question whether we 
should talk about error handling when there's zero evidence that interop 
is relevant. Has anybody *seen* a header field instance like that in 
practice?

>>> D.5.  Extracting the Disposition Type
>>>
>>>    The parsing step (Appendix D.2) has returned the disposition type (to
>>>    be matched case-insensitively), which can be "attachment", "inline",
>>>    or an extension type.  If the type is unknown, treat it like
>>>    "attachment" (see Section 3.2).
>>
>> What if there's no disposition type?
>>
>> Content-Disposition: filename=foo.exe
>> Content-Disposition: foo=bar
>>
>> If I remember correctly, we're supposed to treat the former as inline
>> and the later as attachment.
>
>
> http://greenbytes.de/tech/tc2231/#attmissingdisposition
>
> doesn't seem like there's much consensus among implementers here; unless one forms, I don't think we can say much.

Right.

Going back to the archives -- in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0679.html>, 
Adam says:

> I'll make this change next time I edit the wiki.  Before Julian and
> others bite my head off, I'm aware that this will likely mean you
> won't find this text acceptable to include in the current document.
> If that's the case, I can expand this text to a full-length
> specification, and we can publish it either through this working group
> or as an individual submission.

That was six weeks ago -- Adam, do you still plan to make these changes?

We've been debating this since September, and I don't think we have made 
any progress towards even a rough consensus that we *want* to specify 
error handling. As this specification was only supposed to clarify 
something we already have (C-D in MIME, plus the text in 2616), I 
strongly suggest that we either give up on this and proceed to LC, or 
set a deadline.

Best regards, Julian

Received on Thursday, 3 February 2011 19:15:37 UTC