%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 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.

Adam

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