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 18:58:35 +0100
Message-ID: <4D065ECB.4070409@gmx.de>
To: Maciej Stachowiak <mjs@apple.com>
CC: Adam Barth <ietf@adambarth.com>, httpbis <ietf-http-wg@w3.org>
On 13.12.2010 18:28, Maciej Stachowiak wrote:
>
> On Dec 13, 2010, at 2:55 AM, Adam Barth wrote:
>
>> I've updated the proposal for Content-Disposition error handling on the wiki:
>>
>> http://trac.tools.ietf.org/wg/httpbis/trac/wiki/ContentDispositionErrorHandling
>>
>> I think Julian and I are in agreement by-and-large, except for whether
>> to apply \-decoding or %-decoding to the filename parameter value.
>
>
> 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)

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

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

(I'm sure Adam will fill in the other side of the argument)

> I notice that the ultimate decoding doesn't include the steps where the encoding of the referer is tried, or where an encoding specific to the user's locale is tried. I understand the reasons either of these rules might be problematic to put into the standard, but do we expect that browsers will be willing to drop them? Is it reasonably Web-compatible to do so? If we expect implementations to keep doing these things, then I think the proposal needs to at least give implementations license to try other encodings, even if it doesn't require it. Better to incompletely reflect reality than to require things contrary to what we expect to be implemented.

I'd be very surprised if we can get consensus to standardize something 
that required out-of-band information to decode. That's a severe 
violation of HTTP requirements *and* - and this is the most important 
part - experience shows that UAs do not need to do this (see my test suite).

I understand that some vendors have problems moving away from this 
broken behavior, but that doesn't mean it needs to be documented in 
*this* spec.

Best regards, Julian
Received on Monday, 13 December 2010 17:59:09 GMT

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