Re: HTTP 1.1 --> 2.0 Upgrade

On Mon, Aug 20, 2012 at 3:36 AM, Willy Tarreau <w@1wt.eu> wrote:

> Hi Roberto,
>
> On Mon, Aug 20, 2012 at 03:23:32AM -0700, Roberto Peon wrote:
> > 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).
>
> As we suggested in our network-friendly draft, its possible to send
> multiple
> GET requests at once during the handshake by passing the list of URIs in a
> dedicated header. It basically allows us not to waste the round trip.
>

I agree that this can work, assuming all the URLs fit in the headers (many
servers/proxies have a maximum limit on header size to reduce attack
surface) and no other headers are required.
Having seen some incredible URLs and headers (e.g. cookies), I'm wary of
assuming this is reasonable.
For this to work, it also mandates some annoying interaction between the
HTTP/1.1 code and whatever follows it.


> > Having the data in DNS could short-circuit this, but shouldn't be a
> > dependency.
>
> The DNS requires a round trip anyway and it currently where time is wasted
> in mobile environments.
>

This is an unavoidable round-trip, though. If you don't know where to go,
one must figure that out.


>
> > 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.
>
> Maybe this could still be done over the established connection using an
> Upgrade ? However, I'd hope we avoid announcing IP and ports in exchanges,
> as it will cause the NAT mess we managed to avoid for years with HTTP and
> which made other protocols disappear.
>

I'm not understanding how this would cause NAT messes? I'd guess that most
external sites would just continue to use :80 and :443. Some internal sites
wouldn't, and the network there is controlled well enough that this should
cause no problem. In any case, sites are incented to be sure that users can
connect to them, and will quickly decide to simply keep using :80 and :443.
When one has an inspecting intermediary, it probably won't like to see the
upgrade, but probably would be perfectly fine with a different connection
(e.g. TLS on :443). There is simply less complexity there, imho.

-=R