Re: Optimizations vs Functionality vs Architecture

On port 80, the only thing you can rely upon working is the most commonly
used subset of http/1.1.

Thus, user-agents and servers must handle both upgrade and downgrade as
necessary basically all the time.

-=R
On Aug 22, 2012 5:13 PM, "Amos Jeffries" <squid3@treenet.co.nz> wrote:

> On 23.08.2012 03:11, 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.
>>
>>
> Yes. agreed.
>
> You would face the same upgrade issues if you were to attempt SPDY on port
> 80. But once you change the port you change the assumed protocol away from
> HTTP/1 and enable the NPN upgrade method to identify SPDY vs HTTP/1 vs
> HTTP/2 or whatever.
>
> Our charter as proposed requires that HTTP/2 operate over existing web
> infrastructure. Which means port-80 for a vast majority of networks - where
> HTTP/1 is assumed by every hardware transistor along the way. I see the DNS
> and alternative as optimizations we *might* be able to use for faster
> setup, but cannot guarantee working.
>
> Amos
>
>  On Wed, Aug 22, 2012 at 8:03 AM, Eliot Lear 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?
>>>
>>> Eliot
>>>
>>>
>>>
>
>