On Fri, Mar 13, 2015 at 4:55 AM, Mark Nottingham <mnot@mnot.net> wrote:
> Sorry, just catching up on this spec. Expect some pull requests / issues.
>
Looking forward to them!
> I don't think there's any problem layering in redirect semantics on a 200
> -- it's not pretty, but as pointed out, we already do this elsewhere.
>
> A new 2xx is an interesting idea, but probably overkill.
>
> I wouldn't use Link for this, too many nasty corner cases. E.g., what if <
> http://www.mnot.net/> sends a Link to <https://other.foo.com/bar?baz>?
>
> Just define a new header; they're cheap.
They're cheap in isolation, but expensive in aggregate. We're talking about
a signal that we'd be locking ourselves into pretty much forever. It seems
like we can deal with a little bit of flexibility around how we specify the
redirect behavior if it allows us to avoid permanent cruft in request
headers. That's the main reason I'd prefer just sending the CSP directive
in the response, and allowing the client to decide what to do with it.
That would even have cachability advantages, as we wouldn't need to vary
the response based on request headers: new browsers would see the header,
and navigate the user in response. Old clients would ignore the directive
they don't understand, and render the page.
That seems like a good outcome to me.
-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.)