Re: TICKET 259: 'treat as invalid' not defined

On Sun, Dec 12, 2010 at 3:35 PM, Mark Nottingham <> wrote:
> On 12/12/2010, at 10:03 AM, Adam Barth wrote:
>>>> 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.)
>>> If you did that, you'd be inconsistent with IE8:
>>> <http://localhost:8080/tc2231/#attandinline>.
>> Indeed.  Agreement between all the browsers isn't required to make progress.
> No, but given that according to Julian's tests, all browsers currently ignore headers with multiple disp-types, *except* for IE8, which *doesn't* pick the first one, it seems we have a strong motivation for defining error handling here to be compatible with IE8, so that we don't create yet more incompatibility.

Oh, that's not how I interpret these tests:

Content-Disposition: attachment; inline; filename=foo.html
Content-Disposition: inline; attachment; filename=foo.html

> Do you have any technical justification for another approach?

In both those cases, every browser (except IE8 and possibly Konquerer)
takes the first disposition-type.  I'm just suggesting that we
recommend the error handling behavior implemented by the majority of
the browsers.

>>>>> 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.
>>> <http://localhost:8080/tc2231/#attwith2filenames>
>>> Most UAs do indeed pick the first one, but it would be useful to understand
>>> whether this is purely academic or not. Can you provide any evidence about
>>> happening this in practice?
>> I don't have any data to present at this time.  However, we still want
>> to define how to handle these cases.  If it turns out not to affect
>> any web sites, that's fine.
> As long as it's not a requirement, I don't have any problem suggesting the first one.

Great.  :)


Received on Sunday, 12 December 2010 23:43:16 UTC