Re: [CSP] URI/IRI normalization and comparison

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