Re: HTTP/2.0 -04 candidate

This is something we're pursuing in the next version of SPDY. We haven't
pushed it forward in httpbis because it's half-baked, and our typical
strategy has been to say "yo dawgs, we're interested this area and
exploring it. we'll experiment and report back when we have something
concrete and data to support." This is one reason we've defined a
CREDENTIAL frame in SPDY, and we're talking about pushing DNS info in a new
frame type as well to support this stuff.

But yeah, as you say, we should fork a thread to discuss if interested. I
don't know if folks would rather us discuss it here, or rather the SPDY
folks go off and get impl experience first and report back. Within SPDY
land, we're going to experiment with this no matter what and depending on
how successful that is, come back and discuss here.


On Tue, Jul 2, 2013 at 5:02 PM, Ludin, Stephen <sludin@akamai.com> wrote:

>
> 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
> appealing.
>
> 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.
>
> -stephen
>
>
>