- From: Adam Barth <ietf@adambarth.com>
- Date: Mon, 1 Nov 2010 20:07:07 -0700
- 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. Adam
Received on Tuesday, 2 November 2010 03:08:13 UTC