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

[Mark Nottingham <[e-mail]>]

> On 25 Nov. 2016, at 11:53 am, Martin Thomson <[e-mail]> wrote:
> 
> 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.

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,

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