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

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

From: Adam Barth <ietf@adambarth.com>
Date: Mon, 1 Nov 2010 20:07:07 -0700
Message-ID: <AANLkTimJOy_zDVym-dL7tRDMcJ2JVPCgZB6pEv8DtSju@mail.gmail.com>
To: httpbis <ietf-http-wg@w3.org>
On Mon, Nov 1, 2010 at 5:43 PM, Mark Nottingham <mnot@mnot.net> 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.

Received on Tuesday, 2 November 2010 03:08:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:55 UTC