- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 3 Feb 2011 15:30:05 +1100
- To: Adam Barth <ietf@adambarth.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, httpbis <ietf-http-wg@w3.org>
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 UTC