Re: HTTP 1.1 --> 2.0 Upgrade

For port 80:
What WebSockets has done on port 80 with upgrade seems basically fine. The
part that is unfortunate is that it requires about as much time as doing
the TLS handshake (an additional round-trip).
Having the data in DNS could short-circuit this, but shouldn't be a
dependency.

I still do like the idea of "alternate-protocol", which is extremely poorly
described in the SPDY spec. The idea of alternate-protocol was that the
server adds the header detailing the protocol, port, and negotiation
mechanism. The client, if it understands it, may attempt in parallel one of
the alternate protocols. This allows a switch of protocol and port, and a
possible upgrade (no guarantee, given that HTTP offers plaintext and is
100% completely insecure) to using TLS for HTTP schemes, assuming both
client and server agree to do it. This is separate from an upgrade,
however, in that the new protocol is spoken over a new connection which is
used only after it is established (with the previous connection remaining
in use until supplanted), and thus the transfer of resources is not blocked
by application-layer handshakes at any point in time.

For other-than-port-80:
I prefer something NPN-like, hopefully where the protocol being negotiated
is not exposed (that will be a matter for the TLS WG), is my favorite
w.r.t. :443, as one might guess. The reason, however, is that when someone
decides to do HTTP/3 or something else, I'd like to have left the ground
fertile and helped to prevent the ossification of the web.
In other words, design with the idea that we won't solve the entire suite
of problems on this go-round.

-=R

On Mon, Aug 20, 2012 at 2:35 AM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

> I think we need a lot more explanation of what this intermediary chain
> is and which side of the wall it lies.
>
> Configuration of server side proxies such as squid has zero impact on
> this issue. Server installations that support HTTP/2.0 will be
> appropriately configured.
>
> Are client side proxies really more than a corner case issue today?
> When we first developed them the whole of CERN was sitting on a T1 and
> caching was a critical concern. Only a small percentage of the HTML on
> the Web is even cachable.
>
> Content Delivery Networks have caching but they work in a very
> different way to HTTP caching.
>
>
> I am pretty skeptical as to the value of firewall proxies when most
> let port 443 through.
>
>
>
> On Mon, Aug 20, 2012 at 4:49 AM, Willy Tarreau <w@1wt.eu> wrote:
> > On Mon, Aug 20, 2012 at 10:25:46AM +0200, Julian Reschke wrote:
> >> On 2012-08-20 10:16, Yoav Nir wrote:
> >> >Hi
> >> >
> >> >There's been a recent discussion about signaling support for HTTP 2.0
> in
> >> >the DNS. I think that is a good way to go about it, but it doesn't
> cover
> >> >all cases.
> >> >
> >> >I believe there is value in an upgrade mechanism, for example for home
> >> >routers and other devices that use HTTP for configuration long before
> >> >(if ever) they have DNS entries, let alone SRV records.  While such a
> >> >mechanism may also be useful for HTTPS, something like NPN can be used
> >> >as part of the TLS handshake.
> >> >
> >> >So here's my proposal:
> >> >
> >> > 1. When first connecting to a website, the client begins with HTTP
> >> > 1.0/1.1.
> >> > 2. A server that supports HTTP/2.0 responds with a new header:
> >> >    "HTTP-VERSIONS: 1.1,2.0". This header is included in the server's
> >> >    response to the client's request.
> >>
> >> There's already an "Upgrade" header field for that.
> >
> > +1.
> >
> > All this work has been done over and over for WebSocket, I don't see
> > why we need to reinvent the wheel.
> >
> > Upgrade was designed *exactly* for that purpose and fits it very well.
> > Moreover it is the only one (along with NPN) which considers the
> > intermediary chain, while side-band mechanisms (such as DNS) cannot
> > take that into account.
> >
> > Best regards,
> > Willy
> >
> >
>
>
>
> --
> Website: http://hallambaker.com/
>
>