W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2011

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

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 3 Feb 2011 15:30:05 +1100
Cc: Julian Reschke <julian.reschke@gmx.de>, httpbis <ietf-http-wg@w3.org>
Message-Id: <69918695-2045-456A-B1B4-22AB9683C3C8@mnot.net>
To: Adam Barth <ietf@adambarth.com>

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

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


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


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

Cheers,


--
Mark Nottingham   http://www.mnot.net/
Received on Thursday, 3 February 2011 04:30:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:36 GMT