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

Re: [CSP] URI/IRI normalization and comparison

From: Mike West <mkwst@google.com>
Date: Thu, 15 Jan 2015 15:43:51 +0100
Message-ID: <CAKXHy=dPju8daWMJveXhubhS_9v1CHkBhM4kqkF--MUxOzz07Q@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: Anne van Kesteren <annevk@annevk.nl>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi Brian and Anne!

After reading this thread through, I'm confused. It's clear there's a
problem, but it's not clear what's being suggested as a solution. :)

Would one of you mind summarizing the concrete suggestions? I'm happy to
make whatever spec changes make sense to resolve the encoding problems
you've pointed out.

-mike

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Tue, Nov 18, 2014 at 6:43 AM, Brian Smith <brian@briansmith.org> wrote:

> 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 Thursday, 15 January 2015 14:44:39 UTC

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