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:

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

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


doesn't seem like there's much consensus among implementers here; unless one forms, I don't think we can say much.


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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:56 UTC