site-wide headers


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

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.

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

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

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

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

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.

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.


Received on Wednesday, 28 September 2016 11:00:33 UTC