W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 13 Dec 2010 21:50:15 +0100
Message-ID: <4D068707.1020408@gmx.de>
To: Adam Barth <ietf@adambarth.com>
CC: httpbis <ietf-http-wg@w3.org>, Maciej Stachowiak <mjs@apple.com>
On 13.12.2010 21:34, Adam Barth wrote:
> ...
>>> I think Julian and I are in agreement by-and-large, except for whether
>>> to apply \-decoding or %-decoding to the filename parameter value.
>>
>> I fear this is an overstatement, in particular after you re-added UTF-8
>> detection.
>
> Besides the decoding issue and the UTF-8 detection, does the rest seem
> reasonable to you?  I tried to match the structure and positioning of
> your proposal because those aspects seemed important to you.

The general approach looks more reasonable, although I still we don't 
need to do it. I haven't looked at the the details yet.

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

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

>> 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 20:50:53 GMT

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