W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: CORS performance proposal

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 23 Feb 2015 10:57:41 -0800
Message-ID: <CA+c2ei9m=f6cp+8cU+3iJTpeFWYQVRsY7utRRxfMEwGQdBcwyg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WebAppSec WG <public-webappsec@w3.org>, WebApps WG <public-webapps@w3.org>
On Fri, Feb 20, 2015 at 11:43 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Fri, Feb 20, 2015 at 9:38 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Fri, Feb 20, 2015 at 1:05 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> An alternative is that we attempt to introduce
>>> Access-Control-Policy-Path again from 2008. The problems you raised
>>> https://lists.w3.org/Archives/Public/public-appformats/2008May/0037.html
>>> seem surmountable. URL parsing is defined in more detail these days
>>> and we could simply ban URLs containing escaped \ and /.
>> I do remember that another issue that came up back then was that
>> servers would treat more than just '\', or the escaped version
>> thereof, as a /. But also any character whose low-byte was equal to
>> the ascii code for '\' or '/'. I.e. the server would just cut the
>> high-byte when doing some internal 2byte-string to 1byte-string
>> conversion. Potentially this conversion is affected by what character
>> encodings the server is configured for too, but i'm less sure about
>> that.
> High-byte of what? A URL is within ASCII range when it reaches the
> server. This is the first time I hear of this.

I really don't remember the details. I'd recommend talking to
microsoft since I believe they had done most research into this at the

Keep in mind though that just because URL parsing is defined a
particular way, doesn't mean that software implements it that way.

/ Jonas
Received on Monday, 23 February 2015 18:58:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC