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

whether or not intermediaries support 2.0, if it's server-side 
intermediaries (accelerators and reverse proxies), then you can rely on 
the site operator to sort it out.

If it's client-side, the proxy either supports 2.0 or it doesn't, and 
some deterministic (OOB) way for the proxy to determine whether a 
server supports 2.0 could be really useful.

If it's some other sort of intermediary, then.... if it's to be truly 
transparent, it will need to be updated to handle 2.0.

Adrien

------ Original Message ------
From: "Ian Fette (イアンフェッティ)" <ifette@google.com>
To: "Patrick McManus" <pmcmanus@mozilla.com>
Cc: "William Chan (陈智昌)" <willchan@chromium.org>;"Phillip Hallam-Baker" 
<hallam@gmail.com>;"ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Sent: 16/08/2012 5:56:31 a.m.
Subject: Re: comments on draft-mbelshe-httpbis-spdy-00
>In this scheme, perhaps you get a SRV record that tells you example.com supports 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.
> >
> >
> >
> >
> >
> >
> 
> 
>