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

On 03.10.2010 20:50, Adam Barth wrote:
> On Sun, Oct 3, 2010 at 11:43 AM, Julian Reschke<julian.reschke@gmx.de>  wrote:
>> On 03.10.2010 20:05, Adam Barth wrote:
>>> On Sun, Oct 3, 2010 at 2:29 AM, Julian Reschke<julian.reschke@gmx.de>
>>>   wrote:
>>>> You are claiming that it is insufficient to only accept valid headers.
>>>> Please provide evidence, then we have something to discuss.
>>>
>>> Jungshik Shin says "There are a lot of web sites that do what's
>>> expected by IE."
>>> http://code.google.com/p/chromium/issues/detail?id=118#c1
>>>
>>> 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.
>
> So?  What incentive to user agents have to drop support for
> %-encoding?  More tactilely, my reasoning is as follows:
>
> 1) Internet Explorer is not going to drop support for %-encoding.
> 2) Servers written for IE are not going away anytime soon.
> 3) Some user agents wish to compete in markets that contain these servers.
> 4) Those user agent aren't going to drop support for %-encoding.
> 5) The spec shouldn't forbid something that user agents are going to do anyway.

On the other hand, the spec should define unambiguously what a valid 
message means, so we couldn't have two interpretations.

>> 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).
>
> Does that mean your site doesn't work in Chrome?  More pointedly, does
> your site provide Chrome an incentive to change its behavior?

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.

Best regards, Julian

Received on Sunday, 3 October 2010 19:10:57 UTC