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.)Received on Friday, 13 March 2015 06:46:36 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:47 UTC