W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 25 Nov 2016 11:53:26 +1100
Message-ID: <CABkgnnW2+ewi=YViiNqJgne2WFApEEasje3wwU5RsvEBmNPMjg@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, "Emily Stark (Dunn)" <estark@google.com>
On 24 November 2016 at 20:33, Mike West <mkwst@google.com> wrote:
>> Prettier (and latest) version available at:
>>   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 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.)
Received on Friday, 25 November 2016 00:53:59 UTC

This archive was generated by hypermail 2.3.1 : Friday, 25 November 2016 00:54:02 UTC