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

On 03.10.2010 20:48, Eric J. Bowman wrote:
> ...
> Provided a user agent understands my conformant syntax, that user agent
> is conformant with HTTP.  If that user agent also interprets non-
> conformant syntax, that doesn't mean the user agent doesn't conform to
> HTTP.  I don't see any requirement being imposed on browsers by this
> draft, to remove support for whatever behavior they require or desire.
>
> It is not required for the draft author to present evidence that the
> percent encoding is rarely used.  That entire line of logic simply does
> not apply to HTTP.  Think about my previous example of wget, widely
> re-used by package management systems like ports/pkgsrc, and explain to
> me why HTTP should dictate its behavior based on the market concerns
> of browser vendors.
> ...

Eric,

this issue is indeed about *valid* messages.

See, for instance

   <http://greenbytes.de/tech/tc2231/#attwithfnrawpctenca>:

   Content-Disposition: attachment; filename="foo-%41.html"

According to all relevant IETF specs, this specifies a filename of 
"foo-%41.html".

IE and Chrome decode that as "foo-A.html". This breaks the 
interpretation of valid messages, and is only implemented in IE and Chrome.

I'm fully aware that IE and Chrome are not going to stop doing this 
anytime soon. 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.

Best regards, Julian

Received on Sunday, 3 October 2010 19:00:15 UTC