Re: comments on draft-mbelshe-httpbis-spdy-00

In this scheme, perhaps you get a SRV record that tells you
example.comsupports HTTP/2.0. Great. Does HTTP/2.0 exist on port 80?
If so, although
you know the end target supports HTTP/2, you have no idea about whether
intermediaries support HTTP/2. If it's on a port other than 80/443 you can
presume that if you can establish a connection it will be to a
device/intermediary that understands HTTP/2, but experience shows we're
going to successfully be able to establish connections only ~80% of the
time. Perhaps we hope that firewalls adapt and open up whatever port gets
used, but that's stacking the deck against us already...

On Wed, Aug 15, 2012 at 10:48 AM, Patrick McManus <pmcmanus@mozilla.com>wrote:

> sorry - too much shorthand. This is for http:// urls of course..
> https:// can just use npn on the A address.
>
> race A and SRV queries.. make best practice to bundle SRV answers as
> additional information in responses to A queries. Best experience
> returns an A bundled with SRV. But if you get an A without a bundled SRV
> then go ahead and use it immediately for HTTP/1 and allow a
> upgrade/alternate-protocol to do the bootstrapping that less ideal way.
>
> So its just an optimization.
>
> On Wed, 2012-08-15 at 10:19 -0700, William Chan (陈智昌) wrote:
> > Can you elaborate how SRV would work here from a client perspective?
> > Do you propose making the client block on the SRV lookup? Or are you
> > proposing doing this out of band and switching to HTTP/2.0 if we
> > discover support?
> >
> >
> > http://code.google.com/p/chromium/issues/detail?id=22423#c9 has some
> > of our thoughts on SRV in Chromium.
> >
> >
> >
> > On Wed, Aug 15, 2012 at 6:00 AM, Patrick McManus
> > <pmcmanus@mozilla.com> wrote:
> >         On Tue, 2012-08-14 at 12:24 -0400, Phillip Hallam-Baker wrote:
> >
> >         > If we take architecture seriously, the primary signaling
> >         mechanism for
> >         > HTTP/2.0 should be some form of statement in a DNS record to
> >         tell the
> >         > client 'I do HTTP 2.0'. We might also have some sort of
> >         upgrade
> >         > mechanism for use when the DNS records are blocked but that
> >         should be
> >         > a fallback.
> >
> >
> >         This is my current thinking as well though I'm not tied to
> >         it.. srv in
> >         the base case (with the possibility of dnssec) and something
> >         like
> >         upgrade/alternate-protocol over HTTP/1 as a slower fallback.
> >
> >
> >
> >
> >
> >
>
>
>
>