Subject: site-wide headers

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Sep 2016 21:00:05 +1000

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

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

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

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

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 1 Oct 2016 08:12:55 +0200

Hi Martin,

On Wed, Sep 28, 2016 at 09:00:05PM +1000, Martin Thomson wrote:
> it better suited to HTTP.

In fact that's what I find powerful here. I know *many* places where
these headers are set by the front reverse-proxy, simply because it
ensures that they're uniform across all the servers. But it also
happens that there are exceptions (eg: for static some servers or
certain unrelated applications). With this mechanism, there's almost
nothing to change in the way it works. The admin will just have to
add "HS" to the responses instead of adding all these header fields,
when the reverse-proxy notices that the client provided the valid SM
field. And it also ensures the proxy an simply remove HS: and replace
it with all appropriate headers when it comes from a server where it's
not appropriate at all (you know, some application developers like to
copy-paste when they don't know).

So in fact, it supports everything already supported today but the
smarter way. It's really nice in my opinion.

Cheers,
Willy