Re: detecting support for percent encoding in C-D, was: repeated filename parameters

On 10/4/2010 11:12 AM, Julian Reschke wrote:
> On 03.10.2010 20:43, Julian Reschke wrote:
>> ...
>>> Do you have evidence that, for example, the percent encoding is rarely
>>> used? In the absence of evidence, it's unlikely implementations will
>>> remove support for the behavior.
>>
>> The only reason why legacy servers would use percent-escaping is because
>> they were written for IE only.
>>
>> Every other server will sniff; and at least for the one case where I had
>> to do this, I enabled the IE behavior only for IE. (Every other UA will
>> get RFC2231 encoding).
>>
>> I can't provide empirical data, though.
>> ...
> 
> ...but I *can* provide a link to a thread where the same solution was mentioned:
> 
> "...The solution at the end was to detect IE via the user agent header, do IE's way for
> the filename and do the RFC 2231 way for others. But,
> that's assumes UTF-8 URL encoding is turned on in IE..." --
> <http://lists.w3.org/Archives/Public/public-html/2008Mar/0119.html>

In lieu of handling %-escapes, which were 1) semantically nonsensical in http
response headers (while 2231 would be valid) yet 2) not fully nonconforming,
since they were 7 bit ascii clean, so they did not trip up 7 bit handling...

Why not simply drop filename= as a legacy, nonstandard representation, similar
to the original cookie spec, and replace with name= or similar for all RFC2231
conforming names?

This would allow both user agents and servers to continue to interoperate with
legacy schemas, while offering a bridge to HTTP/1.1 semantics.  The definition
of a name= argument could reasonably be declared to override any filename=
argument observed.

Possibility?

Received on Monday, 4 October 2010 16:48:44 UTC