W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: HTTP/2.0 -04 candidate

From: Ludin, Stephen <sludin@akamai.com>
Date: Tue, 2 Jul 2013 19:02:00 -0500
To: Martin Thomson <martin.thomson@gmail.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <CDF8B29D.4616D%sludin@akamai.com>

On 7/2/13 12:51 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:

>On 2 July 2013 12:28, Ludin, Stephen <sludin@akamai.com> wrote:
>> Do I have that correct?  If so, then I think we will run into a lot of
>> problems around matching the resolution of domain2.com to the IP set for
>> domain1.com.  This is not an uncommon scenario for Akamai at least.  All
>> this means is coming up with a security requirement that leaves the
>> feature useful is going to be tricky.
>Yes, the implementation Roberto describes will break in those sorts of
>scenarios.  That's why we're not doing this yet, I think.

I concur with the other strand of this thread which seems to be coming to
consensus that this is a 'not in the is draft' feature at least.  That
said, I am certainly interested in kicking this around more and coming up
with a workable solution.  It could be that 'same origin' is the
best/safest we can do, but the potential advantages of pushing additional
related resources not on the same domain down the session is very

Here is an idea to chew on.  It has been discussed before, but if there
was a concept of returning multiple certs in the ServerHello which
indicate other common names the origin is authorized to serve I tight
provide a path forward to serving related content from those domains.  For
example, if the origin serves an html response on domain1.com which has
references to objects on otherdomain.com AND the origin has a valid
certificate for otherdomain.com it has a mechanism to 'prove' to the
client that it is authorized to push that content.

At this point I am rewriting TLS as well as getting far from the original
subject.  Probably best to continue in a fresh thread if there is interest.

Received on Wednesday, 3 July 2013 00:02:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC