W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

Re: [CSP] URI/IRI normalization and comparison

From: Brian Smith <brian@briansmith.org>
Date: Mon, 17 Nov 2014 21:43:25 -0800
Message-ID: <CAFewVt51gnn2dTJmq1ezd74pEBVNaGjmRU5j2FBzJGF=n0DL8Q@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Nov 12, 2014 at 12:55 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Wed, Nov 12, 2014 at 9:40 AM, Brian Smith <brian@briansmith.org> wrote:
>> If you get a garbage Location like that for anything other than a
>> redirect, you just ignore it. When you get a garbage Location like
>> that for a redirect, you probably should just show an error page,
>> though you'd have to do a survey of browser implementations to know
>> for sure what to do.
>
> As far as I know, and I have tested these things, is that we need to
> follow it per how I described it.

It is probably better to have the conversation about Location somewhere else.

>> In other words, when processing URLs in HTTP headers, in general you
>> need to deal with the URL according to RFC 3986 rules at the HTTP
>> level, and deal with the URL using HTML5 rules at the HTML level.
>
> That is nonsense.

To be clear:

I said is what the CSP 2.0 spec requires. It isn't something new I am proposing.

Due to interop issues with various kinds of middleboxes, there's going
to be a need for a way to convert any IRI or HTML5 URL into a pure
ASCII URL that fits well into the HTTP syntax. Barring convincing
research to the contrary, everybody should transmit such pure ASCII
URLs.

Making sure that RFC3986 URLs in CSP directives work correctly with
internationalized HTML5 URLs is a must-have for CSP 2, whereas
integrating the WHATWG HTML URL parsing rules into CSP is not a
must-have.

I agree that it would be good to define a way to parse IRIs and/or
HTML5 URLs in CSP directives in both <meta> and the HTTP header.
Whether that should be done for CSP 2 or for a future revision is not
clear. Also, it isn't clear whether that can be deferred; that is, if
CSP 2 requires the browser to reject all non-RFC3986 URLs now, it
isn't clear that it will be OK to change this in a future version of
CSP.

Cheers,
Brian
Received on Tuesday, 18 November 2014 05:43:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC