Subject: Fwd: New Version Notification for draft-nottingham-site-wide-headers-01.txt

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Nov 2016 13:28:13 +1100

FYI, updated draft.

Prettier (and latest) version available at:
  https://mnot.github.io/I-D/site-wide-headers/ <https://mnot.github.io/I-D/site-wide-headers/>

Biggest change in this revision is restricting site-wide headers to a whitelist + a prefix ("site-"). Feedback appreciated.

I talked to a number of folks about this in Seoul, and it seems like some potential implementers have a preference for a header-based approach, rather than creating a JSON data structure with semantics that diverge from headers.

This is my gut feeling too, but it could be that they were agreeing with me because I was there. Another approach is suggested by Mike West here:
  https://wicg.github.io/origin-policy/ <https://wicg.github.io/origin-policy/>

More than anything, I'd like to have a discussion about this and see if we can move forward, in one direction or another (I don't think the differences between the proposals represent insurmountable hurdles). That's because we continue to have new site-wide mechanisms defined, e.g.:
  https://tools.ietf.org/html/draft-stark-expect-ct <https://tools.ietf.org/html/draft-stark-expect-ct>

Cheers,

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-site-wide-headers-01.txt
> Date: 24 November 2016 at 1:20:06 pm AEDT
> To: "Mark Nottingham" <[email-masked]>
> 
> 
> A new version of I-D, draft-nottingham-site-wide-headers-01.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Name:		draft-nottingham-site-wide-headers
> Revision:	01
> Title:		Site-Wide HTTP Headers
> Document date:	2016-11-24
> Group:		Individual Submission
> Pages:		10
> URL:            https://www.ietf.org/internet-drafts/draft-nottingham-site-wide-headers-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-nottingham-site-wide-headers/
> Htmlized:       https://tools.ietf.org/html/draft-nottingham-site-wide-headers-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-nottingham-site-wide-headers-01
> 
> Abstract:
>   This document specifies an alternative way for Web sites to send HTTP
>   response header fields that apply to an entire origin, to improve
>   efficiency.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Nov 2016 15:14:55 +1100

On 24 November 2016 at 13:28, Mark Nottingham <[email-masked]> wrote:
> Biggest change in this revision is restricting site-wide headers to a
> whitelist + a prefix ("site-"). Feedback appreciated.

So the intent is to signal to the client that the header field is
valid for inclusion in the site-wide headers?  Doesn't that make it
odd when you have a header field (like CSP) that is perfectly valid on
a per-resource basis?  Isn't a blacklist easier to work with?  I
realize that doesn't give any potential HTTP overlords the ability to
control what appears, but nonsensical responses will be created with
or without blessing from upon high.

You don't describe the consequences if someone puts a Date header
field in a site-wide resource.  You only say not to.

The example of CSP is particularly enlightening: it has very strict
combining rules:
https://w3c.github.io/webappsec-csp/2/#enforcing-multiple-policies
These rules mean that a site-wide CSP can be deployed, but it would
have to be permissive enough to permit the union of all valid policies
for every resource on the origin.  That's certainly possible, but
potentially inconvenient.  Deploying CSP is already a nightmare.

Text describing how site-wide and local header fields are combined
might help point in the right direction.

You say that site-wide headers are appended, but the natural thing to
do when you hit HS is to insert.

P3P lives!

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Nov 2016 16:40:15 +1100

> On 24 Nov. 2016, at 3:14 pm, Martin Thomson <[email-masked]> wrote:
> 

No, but interesting guess. 

I sketched in a whitelist because site-wide headers are the exception, not the rule, and the designer of the header should really opt into it. Requiring a known prefix and whitelisting existing headers gives you that.

Happy to talk about other approaches, of course, but hopefully with better motivation than you've described.

> field in a site-wide resource.  You only say not to.

Where do I say not to?

> potentially inconvenient.  Deploying CSP is already a nightmare.

Yes. I've never liked that aspect of CSP, but apparently it's necessary for security. IIRC Mike has been working on a default / base CSP policy spec, but I couldn't find it in a quick search of the usual places; Mike? If that gets traction, maybe it should be here instead of CSP.

> might help point in the right direction.

It says append. I suppose I could monkey-patch Fetch, if there's interest. Although in many ways, this kind of happens at a layer "below" Fetch.

> do when you hit HS is to insert.

Mmm, dunno. I think it depends a lot on your implementation. I'm not against that approach, but append seems more... stable (and thus easier to debug?).

> P3P lives!

Unfortunately. <https://www.w3.org/TR/P3P/#Appendix_Working>. You're welcome.

---

From: Mike West <[email-masked]>
Date: Thu, 24 Nov 2016 10:33:58 +0100

On Thu, Nov 24, 2016 at 3:28 AM, Mark Nottingham <[email-masked]> wrote:

>   https://mnot.github.io/I-D/site-wide-headers/
>

Thanks for the update, Mark! It seems like we agree on broad strokes: a
well-known resource defines a set of things for an origin. Clients can
preemptively grab that resource, or a server can push it down. I'm
confident in that model, and I expect we'll be able to work out the
details. :)

> I talked to a number of folks about this in Seoul, and it seems like some
> potential implementers have a preference for a header-based approach,
> rather than creating a JSON data structure with semantics that diverge from
> headers.
>
> This is my gut feeling too, but it could be that they were agreeing with
> me because I was there. Another approach is suggested by Mike West here:
>   https://wicg.github.io/origin-policy/
>

The differences between our proposals seems to boil down to how we wish to
model the "things" that are defined for an origin. The "site-wide headers"
proposal runs with the status quo, HTTP-based approach of response headers
that have origin-wide impact, and standardizes a mechanism of
distinguishing those headers in the future. The "origin policy" proposal
seems like a superset of that approach, allowing legacy headers to be
pinned origin-wide, while also making room for policy definition in a
non-resource-specific way. That seems like a better long-term model to me.

Historically, response headers have been the most convenient way of
establishing origin-wide policy, because they exist and developers can
easily poke at them. It's easier to alter application code to send a new
`Strict-Transport-Security` header rather than, for instance, altering an
HTTP server to send new data as part of a TLS handshake. The mental model,
however, is muddled at best, elevating any arbitrary resource to govern the
entire origin.

The site-wide headers proposal extends this pattern, envisioning a future
where we have a few legacy site-wide headers with strange names, and more
modern site-wide headers with a `site-` prefix. Any arbitrary response may
still exercise control over the site, and each new feature must be modeled
as a response header. I'd prefer to avoid both of these implications.

In fact, I'd suggest that both of our proposals implicitly recognize this
as folly, and choose instead to endow _only_ a particular resource with
origin-wide authority. Neither proposal uses that resource's response
headers to set the policy, but instead the resource's content. I think
we're only talking about headers at all because of historical precedent,
and I'd be pretty happy limiting origin-policy's header-based mechanism to
something like the list in
https://mnot.github.io/I-D/site-wide-headers/#rfc.section.1.1 (probably
with some additions for headers whose ship has sailed, like Emily's
`Referrer-Policy`).

I'm happy with that legacy behavior for things like CSP, because
`Content-Security-Policy` is quite explicitly a resource-specific header
with resource-specific implications. Modeling it as part of a particular
response (even if it's set on an origin-wide basis) seems reasonable: the
developer is claiming "Each of the resources on this origin will have a
policy something like this, but they might differ a bit." `Referrer-Policy`
and `Access-Control-Allow-Origin` are similarly resource-specific. The
origin policy proposal tries to recognize this by giving explicit
"baseline" or "fallback" options for overrides (
https://wicg.github.io/origin-policy/#dom-httpheader-type (regardless of
the approach we take to headers, this bit seems critical to me)).

I'd contrast that legacy behavior with something like the `cors-preflight`
controls sketched out in
https://wicg.github.io/origin-policy/#cors-preflight-member. Things like
this don't make much sense to me as an HTTP response header for any
particular resource, nor could they reasonably differ between resources.
The origin's owner is making declarations about the way Fetch ought to work
for the origin at large, independent of any particular response. I'd very
much prefer not being forced to model it as a `site-cors-preflight:
whatever` header. Likewise, I'd much prefer to suggest to Future Emily that
she define a new `certificate-transparency` member in an origin's policy
manifest rather than a new `Site-CT` header.

-mike

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Nov 2016 20:51:36 +1100

Hey Mike!

> On 24 Nov. 2016, at 8:33 pm, Mike West <[email-masked]> wrote:
> 
> Thanks for the update, Mark! It seems like we agree on broad strokes: a well-known resource defines a set of things for an origin. Clients can preemptively grab that resource, or a server can push it down. I'm confident in that model, and I expect we'll be able to work out the details. :)
>  
> The differences between our proposals seems to boil down to how we wish to model the "things" that are defined for an origin. The "site-wide headers" proposal runs with the status quo, HTTP-based approach of response headers that have origin-wide impact, and standardizes a mechanism of distinguishing those headers in the future. The "origin policy" proposal seems like a superset of that approach, allowing legacy headers to be pinned origin-wide, while also making room for policy definition in a non-resource-specific way. That seems like a better long-term model to me.

Agreed. There are smaller differences around things like syntax and how change is handled, but this is the big one.

The feedback I've had in side conversations so far is that doing it both ways is adding complexity to the platform; it's more clean if there's just one mechanism at work. As a result, I previously suggested changing your proposal so that it's *just* JSON-based policy definition, without any reference to HTTP headers. Sorry I haven't gotten around to making that pull request.

However, more recently I've heard from a number of folks that having HTTP header capability is preferable, which is why I revved my proposal (OK, I also did that to try to kick start this discussion :)

Doing it in a headers-based fashion also has the bonus that proposals like Emily's don't have to block on having this defined.

I'm happy to have my mind changed on all of this. I'm especially happy if there's clear consensus in the community on one end of the spectrum or the other.

Personally, I'd be slightly unhappy if we adopted your current proposal (because it tries to do both things, and that seems overly complex), but would be just fine if we decided to do JSON-based policy definition without reference to HTTP headers (presumably finding a non-generic way to map existing site-wide headers into it, maybe even by just nominating them, rather than putting them in a generic 'headers' bag). 

I would be really really really happy if we decided *anything* relatively quickly, because there are a few opportunities coming up to use such a beast, and I've been gently pushing various proposals along these lines for years.

> Historically, response headers have been the most convenient way of establishing origin-wide policy, because they exist and developers can easily poke at them. It's easier to alter application code to send a new `Strict-Transport-Security` header rather than, for instance, altering an HTTP server to send new data as part of a TLS handshake. The mental model, however, is muddled at best, elevating any arbitrary resource to govern the entire origin.

Agreed. That's where we're at. One of the side benefits of the recent changes I made was that it identifies new site-wide headers with a prefix.

> The site-wide headers proposal extends this pattern, envisioning a future where we have a few legacy site-wide headers with strange names, and more modern site-wide headers with a `site-` prefix. Any arbitrary response may still exercise control over the site, and each new feature must be modeled as a response header. I'd prefer to avoid both of these implications.

I don't know that we can ever get away from an arbitrary response exercising control over the site, when you consider the entire stack; so many features are on a per-origin (or with cookies, greater) scope. 

WRT the latter; HTTP headers aren't a great model, but we're working to make them better. What they have now is developer familiarity. I'd really prefer to avoid making things conceptually more complex if we can.

> In fact, I'd suggest that both of our proposals implicitly recognize this as folly, and choose instead to endow _only_ a particular resource with origin-wide authority. Neither proposal uses that resource's response headers to set the policy, but instead the resource's content. I think we're only talking about headers at all because of historical precedent, and I'd be pretty happy limiting origin-policy's header-based mechanism to something like the list in https://mnot.github.io/I-D/site-wide-headers/#rfc.section.1.1 (probably with some additions for headers whose ship has sailed, like Emily's `Referrer-Policy`).

I think we're thinking along the same lines here...

> I'm happy with that legacy behavior for things like CSP, because `Content-Security-Policy` is quite explicitly a resource-specific header with resource-specific implications. Modeling it as part of a particular response (even if it's set on an origin-wide basis) seems reasonable: the developer is claiming "Each of the resources on this origin will have a policy something like this, but they might differ a bit." `Referrer-Policy` and `Access-Control-Allow-Origin` are similarly resource-specific. The origin policy proposal tries to recognize this by giving explicit "baseline" or "fallback" options for overrides (https://wicg.github.io/origin-policy/#dom-httpheader-type (regardless of the approach we take to headers, this bit seems critical to me)).
> 
> I'd contrast that legacy behavior with something like the `cors-preflight` controls sketched out in https://wicg.github.io/origin-policy/#cors-preflight-member. Things like this don't make much sense to me as an HTTP response header for any particular resource, nor could they reasonably differ between resources. The origin's owner is making declarations about the way Fetch ought to work for the origin at large, independent of any particular response. I'd very much prefer not being forced to model it as a `site-cors-preflight: whatever` header. Likewise, I'd much prefer to suggest to Future Emily that she define a new `certificate-transparency` member in an origin's policy manifest rather than a new `Site-CT` header.

Understood. What do others think?

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Nov 2016 21:10:13 +1100

One other thing --

If we take an approach that doesn't allow fallback to headers for new features, it's going to be important to get broad buy-in from implementers. Otherwise, it'll raise the friction for those new features.

For example, if Expect-CT were to adopt it, and browsers were now required to make an extra fetch to implement the spec, some might not like that, and resist implementing it.

This has been the case when we've discussed similar approaches in the past; the extra fetch -- even when not on the critical path -- adds friction. If that's changed, it's great news -- but we should verify that.

Cheers,

---

From: Mike West <[email-masked]>
Date: Thu, 24 Nov 2016 16:31:48 +0100

On Thu, Nov 24, 2016 at 10:51 AM, Mark Nottingham <[email-masked]> wrote:

> The feedback I've had in side conversations so far is that doing it both
> ways is adding complexity to the platform; it's more clean if there's just
> one mechanism at work. As a result, I previously suggested changing your
> proposal so that it's *just* JSON-based policy definition, without any
> reference to HTTP headers. Sorry I haven't gotten around to making that
> pull request.
>

I'm fine with changing origin policy to just a JSON-based policy
definition. That said, I'm not sure it gains us much if we agree that it's
important to deal with the existing headers that developers are using
today. That is, spelling things `{ "headers": [ { "name":
"referrer-policy", "value": "origin", "type": "fallback" } ] }` is more or
less the same as spelling the same intent `{ "referrer-policy": { "value":
"origin", "override-policy": "something" } }` If anything, I think
pretending that we're not talking about a header in these resource-specific
cases is actually more confusing when it comes to the fallback/baseline
distinction.

I think I'd agree, though, that it makes more sense for the existing
site-wide headers: `{ "transport-security": { "max-age": 10886400,
"subdomains": "include" } }` is simpler to understand than the existing
header-based syntax.

> However, more recently I've heard from a number of folks that having HTTP
> header capability is preferable, which is why I revved my proposal (OK, I
> also did that to try to kick start this discussion :)
>

I think having a header-based system for response-specific headers like CSP
makes a lot of sense. I'm less enthusiastic about forcing ourselves into
headers for everything going forward.

> Doing it in a headers-based fashion also has the bonus that proposals like
> Emily's don't have to block on having this defined.
>

Honestly, Emily is not going to block on this regardless. Even if everyone
shook hands and agreed to implement exactly the -01 site-wide headers
today, it wouldn't be stable in time to be useful.

I'm interested in getting the framework right going forward, but I'm
pragmatic about how long that's going to take, and what short term
tradeoffs might be reasonable in the face of that timeline.

> I'm happy to have my mind changed on all of this. I'm especially happy if
> there's clear consensus in the community on one end of the spectrum or the
> other.
>

It would indeed be helpful for more browser vendors to weigh in, as well as
other clients that might be affected.

> Personally, I'd be slightly unhappy if we adopted your current proposal
> (because it tries to do both things, and that seems overly complex), but
> would be just fine if we decided to do JSON-based policy definition without
> reference to HTTP headers (presumably finding a non-generic way to map
> existing site-wide headers into it, maybe even by just nominating them,
> rather than putting them in a generic 'headers' bag).
>

I'm not heavily invested in the existing syntax, but I do think the
featureset the current origin policy draft offers is important. In
particular, the override bits for resource-specific headers like CSP.

> I would be really really really happy if we decided *anything* relatively
> quickly, because there are a few opportunities coming up to use such a
> beast, and I've been gently pushing various proposals along these lines for
> years.
>

Just to set expectations, I don't have any running code (nor do I have any
idle hands). This is going to take time to implement in Chrome, regardless
of what we decide. :)

On Thu, Nov 24, 2016 at 11:10 AM, Mark Nottingham <[email-masked]> wrote:

> If we take an approach that doesn't allow fallback to headers for new
> features, it's going to be important to get broad buy-in from implementers.
> Otherwise, it'll raise the friction for those new features.
>

It would indeed be helpful for more browser vendors to weigh in, as well as
other clients that might be affected.

> For example, if Expect-CT were to adopt it, and browsers were now required
> to make an extra fetch to implement the spec, some might not like that, and
> resist implementing it.
>

It's certainly a tradeoff. My hope is that we'll more than make up for any
impact with things the feature will enable, like dropping CORS preflights.

> This has been the case when we've discussed similar approaches in the
> past; the extra fetch -- even when not on the critical path -- adds
> friction. If that's changed, it's great news -- but we should verify that.
>

In my mind, H2 push is the relevant primitive that makes this possible. I
think it would have bad performance implications on the initial fetch if
the client had to issue a separate request in the middle of processing the
main page.

-mike

---

From: Emily Stark <[email-masked]>
Date: Thu, 24 Nov 2016 08:08:12 -0800

> to make an extra fetch to implement the spec, some might not like that, and

A feature could always define its own fallback to headers, couldn't it?

> > I talked to a number of folks about this in Seoul, and it seems like
> some potential implementers have a preference for a header-based approach,
> > The differences between our proposals seems to boil down to how we wish
> to model the "things" that are defined for an origin. The "site-wide
> headers" proposal runs with the status quo, HTTP-based approach of response
> headers that have origin-wide impact, and standardizes a mechanism of
> > The site-wide headers proposal extends this pattern, envisioning a
> future where we have a few legacy site-wide headers with strange names, and
> more modern site-wide headers with a `site-` prefix. Any arbitrary response
> may still exercise control over the site, and each new feature must be
> modeled as a response header. I'd prefer to avoid both of these
> implications.
> >
> > In fact, I'd suggest that both of our proposals implicitly recognize
> this as folly, and choose instead to endow _only_ a particular resource
> with origin-wide authority. Neither proposal uses that resource's response
> something like the list in https://mnot.github.io/I-D/
> site-wide-headers/#rfc.section.1.1 (probably with some additions for
> headers whose ship has sailed, like Emily's `Referrer-Policy`).
> >
> "baseline" or "fallback" options for overrides (https://wicg.github.io/
> origin-policy/#dom-httpheader-type (regardless of the approach we take to
> headers, this bit seems critical to me)).
> >
> > I'd contrast that legacy behavior with something like the
> `cors-preflight` controls sketched out in https://wicg.github.io/origin-
> policy/#cors-preflight-member. Things like this don't make much sense to
> me as an HTTP response header for any particular resource, nor could they
> reasonably differ between resources. The origin's owner is making
> declarations about the way Fetch ought to work for the origin at large,
> independent of any particular response. I'd very much prefer not being
> forced to model it as a `site-cors-preflight: whatever` header. Likewise,
> I'd much prefer to suggest to Future Emily that she define a new
> `certificate-transparency` member in an origin's policy manifest rather
> than a new `Site-CT` header.
> >
> > -mike
>
> --

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 Nov 2016 11:36:20 +1100

On 24 November 2016 at 16:22, Jim Manico <[email-masked]> wrote:
> I think a blacklist for security headers has great potential harm. As a developer, I need to know explicitly what security headers are being delivered or someday a UA will start activating headers that I have not tested, am not aware of, and suddenly my site is broken because of a UA update.

I don't see how that concern is relevant in this context.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 Nov 2016 11:53:26 +1100

On 24 November 2016 at 20:33, Mike West <[email-masked]> wrote:
> preemptively grab that resource, or a server can push it down. I'm confident
> in that model, and I expect we'll be able to work out the details. :)

I think that setting these two proposals against each other is
creating fun where no fun is really needed.

I'm of the opinion that a well-known global resource (or set of
resources, because we're already there) that contained specific and
precise policies about an origin is valuable.  As Mike points out,
there are things that you can say more clearly when you aren't
constrained by saying something about a specific HTTP response.
That's a principled position that I can respect.

At the same time, we need to deal with the fact that we've got a bunch
of per-response header fields that are gradually proliferating.  At
some level, we're basically just looking for some better compression
(as Mark's draft points out, HPACK is pretty close to good enough for
this purpose).

The HTTP header fields stuff in Mike's draft is abominable.  I think
that Mark is much closer to an approach that will deploy successfully
for stuff that we currently have - at least in the short term.

Where the tension seems to come from is that all the existing stuff is
basically stuck in header fields for the foreseeable future.  That's
unpleasant, because even if we were to define principled equivalents
in terms of Mike's draft, then we're still stuck supporting header
fields indefinitely.  It makes the work to define the principled thing
much less appealing, because now you have two mechanisms to do the
same thing with all the duplication and conflicts that come from that.

(And hey, sorry for making this all personal by using names to
identify drafts, I'll try harder next time.)

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 Nov 2016 12:08:31 +1100

> I sketched in a whitelist because site-wide headers are the exception, not the rule, and the designer of the header should really opt into it. Requiring a known prefix and whitelisting existing hea…

I don't see much value in them then.  As I said, sites are perfectly
capable of generating rubbish.

Add that to the bad taste that having people claim large swathes of
the header field name space leaves if you like.

>> field in a site-wide resource.  You only say not to.

By saying that the header field has to be on the whitelist, you
implicitly forbid inclusion of other header fields.  But you don't
define rules for what to do if you see a header field that is not on
the whitelist.  Do you throw out the whole .wk resource?

> It says append. I suppose I could monkey-patch Fetch, if there's interest. Although in many ways, this kind of happens at a layer "below" Fetch.

Append works for me, but you aren't clear enough.  And I think that
you will find that Fetch (or is it just fetch?) wants control over
this stuff.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 25 Nov 2016 13:21:16 +1100

> On 25 Nov. 2016, at 3:08 am, Emily Stark <[email-masked]> wrote:
> 
> 
> 

It could, but doing so would raise implementation cost; either on the client side (requiring clients that support the JSON form to also always support the header form, always, or the server side (requiring sites to always host the JSON and send the headers, unless the client says it has the JSON). 

Putting the requirement on the client probably makes more sense (they're less diverse), but then if you want to take advantage of the JSON syntax, you'd have two parsers, and the possibility of divergence in their behaviour. 

None of this is a deal killer IMO, just worth noting.

Once the JSON format enjoys wide adoption in browsers, new features can stop specifying the header fallbacks. If that takes a long time, or never completes (e.g., one browser decides not to do the JSON), it'd be a suboptimal outcome.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 25 Nov 2016 13:32:54 +1100

> On 25 Nov. 2016, at 11:53 am, Martin Thomson <[email-masked]> wrote:
> 

Well described, although migrating *existing* site-wide things away from headers is only a nice-to-have goal for me; the real goal is to avoid the need to define future ones (or at least to put them on the wire very often, depending on which way we go).

If I read things correctly, one strong possibility is to take the generic "headers" out of Mike's spec and define syntax for existing site-wide headers on a case-by-case basis. That gets existing site-wide headers off the wire for those clients that implement, although they will still need to be able to deal with the header version for the foreseeable future.

I think that's a fine outcome (because it's effectively a graceful transition) if we can get a commitment to implement from most/all browsers (or "convince" them to do it relatively soon). If we can't, we're effectively stuck with site-wide headers for existing *and* future things, no matter what we do; see separate thread with Emily.

Thus the repeated requests for other browser folk to chime in.

Cheers,

---

From: Stefan Eissing <[email-masked]>
Date: Sat, 26 Nov 2016 15:29:42 +0100

> Am 25.11.2016 um 03:32 schrieb Mark Nottingham <[email-masked]>:
> 
> 

Well, from a server PoV, supporting this for existing headers is not straight forward. Headers can be injected into the response at several stages of processing and some may already be on the wire when the server finds out that a "side-wide" header was changed.

Servers would need to know the complete set of headers before sending the first one or, alternately, preventing application code to insert such headers from a certain point in time onwards. I am almost certain that this will break some deployments.

If the whole purpose - for existing headers - is to save some bytes on the wire, then I find it hard to justify the complexity in these days of h2 and hpack.

-Stefan

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 27 Nov 2016 18:38:52 +1100

Hi Stefan,

> On 27 Nov. 2016, at 1:29 am, Stefan Eissing <[email-masked]> wrote:

Are you talking about handling responses in flight when the .well-known file is updated, or something else?

> Servers would need to know the complete set of headers before sending the first one or, alternately, preventing application code to insert such headers from a certain point in time onwards. I am al…

I think you're over-complicating it. In Apache, .htaccess files don't prevent you from inserting (e.g.) Strict-Transport-Security if CGI or PHP already did so; why is this different?

> If the whole purpose - for existing headers - is to save some bytes on the wire, then I find it hard to justify the complexity in these days of h2 and hpack.

See the intro of my doc. HPACK has per-connection overhead, so if we keep on adding headers, it's going to get crowded in there, and that takes memory server-side. Doing a .well-known (of whatever flavour) is per-origin, so it takes the pressure off of HPACK. Because it persists beyond a connection, it also means you spend less time at the beginning of each conn setting up HPACK state.

Cheers,

---

From: Stefan Eissing <[email-masked]>
Date: Sun, 27 Nov 2016 17:22:48 +0100

Hi Mark,

> Am 27.11.2016 um 08:38 schrieb Mark Nottingham <[email-masked]>:
> 
> Hi Stefan,
> 

I was thinking of someone at the end of the request output filtering adding a header like access-control-allow-origin. It might be mistaken, but that header only allows a single value.

If there is the same header in the well-known site-wide definition, it would cause a problem, it seems to me. The client appends the sh headers and sees duplicate values, right?

> See the intro of my doc. HPACK has per-connection overhead, so if we keep on adding headers, it's going to get crowded in there, and that takes memory server-side. Doing a .well-known (of whatever…

I agree with the goal of this spec. I am not certain it will work for all headers listed. There are obvious once where it does and others, with the example above, where it might not be straightforward. 

Cheers, Stefan

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 29 Nov 2016 10:52:23 +1100

> On 28 Nov. 2016, at 3:22 am, Stefan Eissing <[email-masked]> wrote:
> 
> Hi Mark,
> 

Yep. My thinking is that this is no different than any other potential clash caused by a configuration mechanism -- the solution is "don't do that."

> I agree with the goal of this spec. I am not certain it will work for all headers listed. There are obvious once where it does and others, with the example above, where it might not be straightforw…

We definitely need to go through the headers and evaluate each one, no matter what mechanism we choose.

Cheers,