Subject: Ticket 262: Discuss whether percent-decoding should also be done by receivers.

From: Adam Barth <[email-masked]>
Date: Mon, 1 Nov 2010 20:07:07 -0700

On Mon, Nov 1, 2010 at 5:43 PM, Mark Nottingham <[email-masked]> wrote:
>> http://tools.ietf.org/html/draft-ietf-httpbis-content-disp-03#appendix-C.2
>>
>> As far as I can tell, this is actually the biggest interoperability
>> problem with the Content-Disposition header field.  Unfortunately,
>> this document does nothing to resolve this issue.  I recommend that
>> this document take a position with respect to how to handle
>> percent-encoded values in the filename parameter.  Specifically, I
>> recommend that the document instruct user agents to decode percent
>> encoded values using the user's preferred encoding.  Yes, that's ugly,
>> but it's the way Content-Disposition works in the real world and the
>> most likely requirement to actually be implemented by user agents.
>
> Could you expand upon this a bit more? E.g., are you saying that after the 5987 encoding is removed, the resulting string should be percent-decoded? Or that the filename (no *) parameter should be percent-decoded? Both?

Assume, for the moment, we have an algorithm for extracting a sequence
of bytes called the filename-parameter-value from the
Content-Disposition header field value.  Here's my proposal:

1) Let the users-default-encoding be the user's preferred encoded
(e.g., as configured as the default encoding used by the user's
operating system).
2) Let unescaped-filename-parameter-value be the result of applying
the percent-unescaping algorithm to filename-parameter-value.
3) Let the requested-filename by the result of decoding the
unescaped-filename-parameter-value with the users-default-encoding.

> Raising as a placeholder:
>  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/262
>
> I suspect that this issue is going to be similar to #259; i.e., the answer may be different for different implementers. As such, we should try to figure out if that's the case (and why) first.

The use case is that this behavior is required to compete in some
segments of the browser market.  Therefore, some number of popular
user agents will not remove support for these semantics.  Pretending
that these semantics don't exist is disingenuous.

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Nov 2010 12:37:03 +1100

On 02/11/2010, at 2:07 PM, Adam Barth wrote:

> user agents will not remove support for these semantics.

Well, *some* form of internationalisation is necessary to compete in segments of the browser market; it's not (yet) clear that *your* form of internationalisation is.

AFAICT this argument boils down to:
 1) FF, Safari and Konqueror support the RFC5987-stype encoding, with some caveats re: ordering and precedence.
  2) IE and Chrome support %-encoding the filename parameter, with some caveats re: charset.

You (representing Chrome?) are arguing for #2. 

IE (unfortunately, although true to form) hasn't said much about this, but based on Eric Lawrence's blog <http://blogs.msdn.com/b/ieinternals/archive/2010/06/07/content-disposition-attachment-and-international-unicode-characters.aspx>, it looks like they don't have a problem with using the RFC5987-style encoding, but do have a strong preference for using a new parameter name, rather than an existing one.

To me, the strongest argument against #2 is that specifying percent-encoding for filename automatically brings out interoperability issues with existing, deployed browsers that don't support encoding in the filename parameter. 

OTOH #1 has a fallback strategy; by placing the filename parameter first, a server can serve an internationalised filename to a UA that can use it, whilst falling back to a "vanilla" filename for those who don't. It's true that support for this isn't widespread now (according to <http://greenbytes.de/tech/tc2231/#attfnboth>), but at least there's a strategy in place for getting from here to there without breaking anything. To make it complete, I agree with the notion that we can warn servers away from generating filename parameters with literal % in them, because there's no interop there.

Overall, then, I don't see how we can get to interop cleanly on percent-encoding the filename parameter, or why we should do so. Yes, some implementations do it today, but that does't lead to the conclusion that we can or should specify their behaviour for all other implementations -- especially when that solution makes things more complex (re: charset). 

What am I missing?

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 03 Nov 2010 06:55:39 +0100

On 03.11.2010 02:37, Mark Nottingham wrote:
> ...
> OTOH #1 has a fallback strategy; by placing the filename parameter first, a server can serve an internationalised filename to a UA that can use it, whilst falling back to a "vanilla" filename for those who don't. It's true that support for this isn't widespread now (according to<http://greenbytes.de/tech/tc2231/#attfnboth>), but at least there's a strategy in place for getting from here to there without breaking anything. To make it complete, I agree with the notion that we can warn servers away from generating filename parameters with literal % in them, because there's no interop there.
> ...

There's only one UA doing this wrong right now, and that's Firefox (for 
which a patch is available).

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 9 Nov 2010 13:13:11 +1100

I think we can close this as 'wontfix' for the current content-disposition spec, #245 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/245> noted that %xx in the filename isn't interoperable. If we add an appendix for error-handling, that might specify handling of percent-encoding, of course.

Thoughts?

On 03/11/2010, at 4:55 PM, Julian Reschke wrote:

> There's only one UA doing this wrong right now, and that's Firefox (for which a patch is available).
> 
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 09 Nov 2010 10:28:38 +0100

On 09.11.2010 03:13, Mark Nottingham wrote:
> I think we can close this as 'wontfix' for the current content-disposition spec, #245<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/245>  noted that %xx in the filename isn't interoperable. If we add an appendix for error-handling, that might specify handling of percent-encoding, of course.
>
> Thoughts?

Yes, let's close it.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 12 Nov 2010 23:28:27 +1100

Closed as WONTFIX.