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

draft-nottingham-httpbis-origin-frame

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Mon, 14 Mar 2016 13:40:12 -0400
Message-ID: <CAOdDvNo2TpVLkE+7o5L6OcxN6G7sWuAYnRF6OXM1LA7xYd2PJg@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
I support draft-nottingham-httpbis-origin-frame for wg adoption, if it were
to be put forward.

I think it is a little unclear on whether or not it intends to include the
use case of advertising origins that are covered by the traditional notion
of authoritative (i.e. certificate checks, key pin, et al) but not
necessarily overlapping DNS. I guess, upon reading, that it doesn't mean to
include that - but I think it should.

The DNS restriction of 7540 is really about sane routing of requests to the
right server by getting an opt-in that indicates configuration. Its not
really about security - DNS is not really part of the security model.

Its a reasonable bootstrap, but DNS is rather imperfect for this signal; as
much as we like to imagine a single and consistent DNS space that's not the
way it translates in practice. Concerns over load balancing are just one of
many reasons why a strict application of 7540 might not allow for
coalescing where it was actually setup and desired. This seems as likely as
the 421 case that motivates the draft. Both could be addressed.

The origin frame is a place to put a strong signal that this established
connection is suitable for the following set of origins no matter what the
clients view of the DNS. (subject to certificate rules, of course). Indeed
it would have the interesting property of removing the need to resolve DNS
for the client for matching origins which is a definite additional
performance win too even in cases where the DNS does overlap.

Plausibly these extension frames could get fairly big. It would seem easy
enough to define them as optionally compressed (with the header compression
state) in the presence of a settings ack of the extension (and a flag bit).

As an aside, it probably makes sense at this time (different document) to
add (back) the extension for including more certs serialized into the
connection to allow more origins to be advertised.

If there is interest, I'd be happy to work on those 3 points.

-Patrick
Received on Monday, 14 March 2016 17:40:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC