Re: site-wide headers

Hey Martin,

CC:ing Mike to make sure he sees this. Mike, there's been a few messages on the HTTP WG list, you might want to have a look.

> On 28 Sep. 2016, at 9:00 pm, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> (https://tools.ietf.org/html/draft-nottingham-site-wide-headers-00)
> 
> I like this approach because it is more obviously composable into an
> existing system at the consuming end.  I especially like that the
> format is without opinion about its contents.  That makes it quite
> powerful.
> 
> I dislike this approach (in contrast to the JSON-based
> origin-policy[1]) because it uses header fields.  Of course that makes
> it better suited to HTTP.  I dislike that the format is without
> opinion about its contents.  That makes it quite powerful.

Mike and I have been talking about the proposals in back channel a bit. A modified origin-policy could take yet another path -- it could not try to convey headers at all, but instead just describe site-wide policy in JSON, defining new syntax to supplant existing site-wide headers where necessary. 

(the downside here being a nasty period where sites have to set up .well-known files *and* send response headers, and not mess it up)

I'm not yet convinced which approach is better, but I'm fairly convinced that it should be one or the other ("just headers" or something new), not both.

One of the advantages of doing this as "just headers" is that, as others on the thread have noted, it's easier for a hoster / CDN / etc. to insert/enforce policy in a way that's more purely mechanical.

I'm probably going to continue working on the site-wide draft as well as send Mike some friendly pull requests; hopefully as we discuss this problem area, the right approach will become more apparent.

> On balance, I think that this is a distinct improvement.

Please disambiguate "this"?

> One thing that this can't do but the origin-policy does is do
> something to manage the downside of CORS.  The idea that you might
> give out a pass to avoid CORS preflight is very appealing.  As far as
> I can tell, this proposal cannot address that problem.  It would be
> justifiable to say that this is a completely different problem that
> might build on this work, but it's a very appealing problem to look
> at.

Yes, I'd intended anything like that to be separately defined, as a new HTTP header, with the site-wide approach.

> (It's tempting to suggest that you could include a label that just
> applies to preflight requests, but I don't know how to solve the
> origin enumeration problem.  origin-policy seems to punt on that.)
> 
> 
> ---Nits and suggestions
> 
> I think that this needs a little more rigour in the definition of the
> format and the algorithm.  They should at least match.  It's unclear
> from the algorithm how blank lines (CRLF CRLF) are handled.

Agreed, if it goes forward.

> The character set for labels could be expanded a little to include
> [0-9\-_] so that you can base64url things you might have lying around
> to produce the label (or just keep the label very short).

Nod.

> You should also note another reason to keep things out of the h2
> header table: any change to the table eventually pushes entries out,
> necessitating re-creation.  This is more manageable because it is
> directly under control.

Yeah, that's not explicitly stated, but it's a strong motivation.

> The draft should note that these advantages come with a cost in memory
> to clients and that clients that receive unreasonably large header
> sets can/should pretend that they don't exist.

Nod. The nice thing is that they're per-origin, not per-connection, but it does have tradeoffs. 


> [1] https://wicg.github.io/origin-policy/


--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 4 October 2016 08:02:20 UTC