Re: %encoding in filename parameters. Re: repeated filename parameters, Re: Working Group Last Call: draft-ietf-httpbis-content-disp-02

On Sun, Oct 3, 2010 at 1:35 PM, Julian Reschke <> wrote:
> On 03.10.2010 22:22, Adam Barth wrote:
>> On Sun, Oct 3, 2010 at 1:15 PM, Julian Reschke<>
>>  wrote:
>>> On 03.10.2010 21:21, Adam Barth wrote:
>>>> On Sun, Oct 3, 2010 at 12:03 PM, Julian Reschke<>
>>>>  wrote:
>>>>> The site I worked on (an SAP content management system) indeed will not
>>>>> work
>>>>> with Chrome, unless it has been fixed since Chrome came out (which I
>>>>> doubt
>>>>> because that system is in "maintenance mode"). It will send the
>>>>> RFC2231-encoded parameter, and Chrome will not "get" the "filename*"
>>>>> parameter. If RFC 2231 support was added in Chrome, the problem would
>>>>> simply
>>>>> go away with no server change being required.
>>>> I don't think anyone has opposed adding RFC 2231 support.
>>> Well, IE has since 2003, and Chrome since it came out.
>> I am confused.  Aren't we talking about syntax like the following?
>> Content-Disposition: attachment; filename*=UTF-8''%e2%82%ac%20rates
>> I'm happy talk to twist the arm of anyone on the Chrome team who
>> doesn't think we should implement that syntax.
> Please do (and no, I don't think I raised a bug report for those after
> seeing the response on
> <>, but see comment #5
> over there).

I basically agree with Jungshik Shin that we'd be better off with only
UTF8 and skipping the language decoration, but I'm not sure it's worth
fighting about.

> Note that I asked multiple browser vendors not implementing RFC 2231 a few
> years ago, and they complained about vagueness (which encodings do we need
> to support?) and unneeded complexity (continuation lines). We fixed those in
> RFC 5987.

Great.  I don't have time to write the patch myself, but I'd be happy
to review a patch written by you or someone else that implements this


Received on Sunday, 3 October 2010 20:50:53 UTC