Re: Updated Content-Disposition error handling proposal on the wiki

On Mon, Dec 13, 2010 at 12:50 PM, Julian Reschke <> wrote:
> On 13.12.2010 21:34, Adam Barth wrote:
>>> 1) for \-decoding
>>> + it's what the spec says (not this one, but the previous one)
>>> + it keeps handling \ in quoted-string consistent across header fields
>>> (hopefully allowing re-use of code)
>>> + it's implemented in some UAs (Opera and Konqueror)
>>> + it's unlikely to cause any regression in UAs that currently do not do
>>> it,
>>> as "\" needs to be special-cased in the layer above as well (essentially
>>> stripped out)
>> 1) against \-decoding
>> + IE, Firefox, Safari, and Chrome do not \-decode.
>> + The \ character is the path separator on Windows, so \-decoding is
>> likely to break sites that include absolute or relative paths in the
>> filename parameter instead of just the leaf file name.
> If they do they are in trouble anyway, because including a path separator
> indicates either a bug, or a deliberate attempt to make the client do
> something stupid.
> It would be helpful if you gave an example of a header value where you think
> that doing the decoding is harmful in practice.

I've done that several times before.

>> I can certainly see the argument for \-decoding on aesthetic and
>> spec-lawyering grounds.  However, in practice, none of the major
>> browsers ever implemented that requirement and doing so now seems more
>> costly than it's worth.
> Not doing so causes ongoing maintenance cost, and additional cost for new
> implementations.
> At the end of the day: this is what the specs have been saying for 10 years.
> Just saying: "we don't think it's needed" simply is not sufficient to remove
> it.
>> IMHO, we should remove the \ character from the server profile of the
>> Content-Disposition header so that we can skip \-decoding in the error
>> handling section without diverging on the interpretation of valid
>> headers.
> -1
>>> 2) against %-decoding
>>> + it makes passing the "%" impossible
>>> + it's in violation of the current specs
>>> + it's not interoperable (only Chrome and IE do it), so changes the
>>> interpretation of currently valid messages
>> 2) For %-decoding
>> + IE is unlikely to stop %-decoding the Content-Disposition header, so
>> if we're going to get browsers to converge on a single behavior, it's
>> going to be much easier to get all the browsers to adopt %-decoding.
> We haven't heard anything from IE, so we don't know.
> If we always standardized on what IE does, we'd end with very funny specs.
> Also, why doesn't the same argument apply to all other decisions you're
> making?

In the absence of hard data, many of these decisions are judgement
calls.  In general, doing things differently from IE requires careful
thought.  Is there some other specific behavior you have in mind?  The
only one that comes to mind is our using the first disposition-type
rather than the last disposition-type.  In that case, every other
non-IE browser uses the first disposition-type, so that seemed like
the thing to do.

>> + There is anecdotal evidence that web sites in the Asian market
>> %-encode their Content-Disposition headers.  Supporting this behavior
>> appears to improve a browsers ability to compete in Asia as little or
>> no cost in other markets.
> Yes, anecdotal. We'd like to see data.

Yes.  Data would make it easier to make the correct decision.


>>> Notice that both questions would be less important if the sender could
>>> rely
>>> on the presence of RFC5987 support (because it introduces a more robust
>>> way
>>> to send those characters).
>> Yep.  That's why these instructions include RFC5987 support.
>>> (I'm sure Adam will fill in the other side of the argument)
>> Done.
>> Adam
> Best regards, Julian

Received on Monday, 13 December 2010 21:03:29 UTC