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

On Mon, Dec 13, 2010 at 6:51 AM, Julian Reschke <> wrote:
> On 13.12.2010 11:55, Adam Barth wrote:
>> I've updated the proposal for Content-Disposition error handling on the
>> wiki:
> and I re-added some of my comments (marked as such).


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

> I do agree that this is much better than what you started with,

Thanks.  I'm glad we're making progress.

> but I still
> think it's a bad idea to standardize behavior for broken headers when
> there's no evidence this is needed, and in particular when it also breaks
> the interpretation of valid headers.

I understand that.  :)

On Mon, Dec 13, 2010 at 9:58 AM, Julian Reschke <> wrote:
> On 13.12.2010 18:28, Maciej Stachowiak wrote:
>> In brief, what are the arguments for and against \-decoding and %encoding
>> respctively?
> 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.

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.

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

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

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



Received on Monday, 13 December 2010 20:36:01 UTC