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

From: Adam Barth <[email-masked]>
Date: Mon, 13 Dec 2010 02:55:21 -0800

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.

Kind regards,
Adam

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Dec 2010 15:51:41 +0100

> http://trac.tools.ietf.org/wg/httpbis/trac/wiki/ContentDispositionErrorHandling

and I re-added some of my comments (marked as such).

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

I do agree that this is much better than what you started with, 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.

Best regards, Julian

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 13 Dec 2010 09:28:54 -0800

> to apply \-decoding or %-decoding to the filename parameter value.

In brief, what are the arguments for and against \-decoding and %encoding respctively?

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.

Regards,
Maciej

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Dec 2010 18:58:35 +0100

> 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 eithe…

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

---

From: Adam Barth <[email-masked]>
Date: Mon, 13 Dec 2010 12:34:53 -0800

> and I re-added some of my comments (marked as such).

Thanks.

> I fear this is an overstatement, in particular after you re-added UTF-8

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 <[email-masked]> wrote:
> + 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
headers.

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

Done.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Dec 2010 21:50:15 +0100

On 13.12.2010 21:34, Adam Barth wrote:
> ...

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.

> ...

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.

> browsers ever implemented that requirement and doing so now seems more

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.

> handling section without diverging on the interpretation of valid

-1

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

> no cost in other markets.

Yes, anecdotal. We'd like to see data.

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Mon, 13 Dec 2010 13:02:29 -0800

On Mon, Dec 13, 2010 at 12:50 PM, Julian Reschke <[email-masked]> wrote:
>>> it,
> 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.

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

> Yes, anecdotal. We'd like to see data.

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

Adam

>>> rely

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Dec 2010 22:22:13 +0100

> I've done that several times before.

Pointer, please. I recall one example to which I responded and didn't 
get any feedback.

See <http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0536.html>.

> rather than the last disposition-type.  In that case, every other

For example.

> non-IE browser uses the first disposition-type, so that seemed like

IE8 doesn't appear to sniff for UTF-8; see 
<http://greenbytes.de/tech/tc2231/#attwithutf8fnplain>.

Best regards, Julian

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 14 Dec 2010 10:06:21 +0900

> On Mon, Dec 13, 2010 at 6:51 AM, Julian Reschke<[email-masked]>  wrote:

>> + it makes passing the "%" impossible

??? % can be passed as %25, or not?

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 14 Dec 2010 15:47:23 +0900

On 2010/12/14 2:28, Maciej Stachowiak wrote:
> 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?

The Web does not assume that client and server use the same encodings. 
Therefore such rules are inherently Web-INcompatible. The sooner the 
implementers can drop it, the better.

Regards,    Martin.

> 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.
>
> Regards,
> Maciej
>
>
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Dec 2010 08:04:26 +0100

> ??? % can be passed as %25, or not?

Yes, but only to those UAs that *do* the unescaping. Others will see "%25".

Note that Adam's proposal (Adam, correct me if I'm wrong) is to disallow 
sending "%" in filenames, and let percent-decoding happen as part of 
error recovery.

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Tue, 14 Dec 2010 00:36:42 -0800

On Mon, Dec 13, 2010 at 11:04 PM, Julian Reschke <[email-masked]> wrote:
> sending "%" in filenames, and let percent-decoding happen as part of error
> recovery.

I don't really care what we recommend servers send.  That's not really
any of my business.  I do care how the header field is processed by
user agents.

Adam