- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 25 Nov 2016 11:53:26 +1100
- 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