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

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

From: Adam Barth <w3c@adambarth.com>
Date: Sun, 3 Oct 2010 12:21:03 -0700
Message-ID: <AANLkTim1fBsH+y4nZRpfoOdF4bAujxsHGob2EeSQedMJ@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Sun, Oct 3, 2010 at 12:03 PM, Julian Reschke <julian.reschke@gmx.de> 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.

On Sun, Oct 3, 2010 at 11:59 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> I'm fully aware that IE and Chrome are not going to stop doing this anytime
> soon.

What's the point of forbidding user agents from doing something we
know they're going to do anyway?  That just makes the specification a
work of fiction.  Rather, the document should explain that it's
defining a subset of the semantics that works across user agents.
That's useful and truthful.

> The best way to workaround this issue is to require that clients
> support the RFC 5987 encoding, which would allow to unambiguously encode the
> name. Unfortunately, we aren't there yet.

That's not at issue here.

Received on Sunday, 3 October 2010 19:22:08 UTC

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