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

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 11:50:40 -0700
Message-ID: <AANLkTi=odSq_sWUyrFE1sFQLOXfOE2tgWePGrvB1g9rq@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 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.

> 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?

Received on Sunday, 3 October 2010 18:51:40 UTC

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