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

> Am 25.11.2016 um 03:32 schrieb Mark Nottingham <mnot@mnot.net>:
> 
> 
>> On 25 Nov. 2016, at 11:53 am, Martin Thomson <martin.thomson@gmail.com> 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.

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

Received on Saturday, 26 November 2016 14:30:17 UTC