- From: Albert Lunde <atlunde@panix.com>
- Date: Wed, 22 Aug 2012 11:36:02 -0500
- To: James M Snell <jasnell@gmail.com>
- CC: Eliot Lear <lear@cisco.com>, Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
On 8/22/2012 10:11 AM, James M Snell wrote:
> I would say no. It's no different, for instance, than using any other
> tcp-based protocol.. you wouldn't use http to determine if ftp is
> supported, for instance. The upgrade path should only be required when
> we try to use HTTP 2.0 on port 80.
>
> On Wed, Aug 22, 2012 at 8:03 AM, Eliot Lear <lear@cisco.com
> <mailto:lear@cisco.com>> wrote:
> On 8/22/12 4:43 AM, Amos Jeffries wrote:
> > * DNS SRV records easily perform end-to-end detection. But HTTP
> > requires next-hop detection.
>
> Is that true for ports other than 80? That is- if you have an
> indication to use, say, port 880, and you're going right to SPDY, do you
> need next-hop detection for purposes of versioning at least?
It's a bit like path-MTU detection, too. If you want to account for HTTP
proxies (and more obscure intermediaries) in the path to the server, you
may need to know something of what might be happening end to end. What
is the least-common-denominator that is supported?
This is where DNS records like SRV or the proposed URI can't give the
complete picture.
Another case is a gateway that does protocol conversion: say a phone
provider wants all their phones to speak HTTP 2.0, and provides a
gateway to downgrade to HTTP 1.1 or 1.0.
--
Albert Lunde albert-lunde@northwestern.edu
atlunde@panix.com (address for personal mail)
Received on Wednesday, 22 August 2012 16:36:24 UTC