Subject: Re: HTTP 1.1 --> 2.0 Upgrade

From: Greg Wilkins <[email-masked]>
Date: Mon, 1 Oct 2012 09:49:42 -0700

Patrick,

this is a good analysis, but my main quibble is that case 3b should be
renumbered to be case 0

Connecting to port 80 and upgrading to the protocol/version that you
want to use should be the basically defined way that a http semantic
connection is established, regardless of wire protocol and version
used.  All other mechanisms (NPN on 443, DNS SRV, cached redirection
to known HTTP/2.0 ports) should all be considered as optimisations of
the basic case.

Saving round trips is important and I'm all for optimisations for that
- but I think it is a MUST that HTTP/2.0 will work in an environment
where there is only port 80 and the ability to make a single
connection.

So I guess that means I support both  3a and 3b.

cheers

PS.  Does upgrade really mean an extra round trip?  Can't we pipeline
HTTP/2.0 request behind the upgrade request if we are confident of
success?

On 20 August 2012 06:45, Patrick McManus <[email-masked]> wrote:
> In vancouver we agreed not to slaughter too many bytes over mandatory
> TLS; but we also talked about the need to describe how HTTP/2 binds to
> TLS. I'm going to narrowly scope this email to the issues involved with
> those situations and how the upgrade should, imo, work without getting
> into every detail:
>
> Case 1: https:// scheme - go to the port in the url (default 443) and
> use NPN to select http/2 or http/1 (default is http/1 in the case NPN is
> not implemented on the server)
>
> Case 2: http:// scheme with default port - optimistically consult DNS
> SRV looking for either http2-tls or http2-plaintext depending on what
> the client wants. If you get a SRV result back "quickly" go to the host
> and port provided and start speaking http2 over tls or plaintext as
> appropriate. No extra indirections, no use of http/1. Reasonable server
> implementations are forseeable.
>
> Case 3: http:// scheme with an explicit port or lack of SRV information.
> This is where we need to bootstrap from HTTP/1. AFAICT people want two
> different patterns:
>
> Case 3a: Direct the traffic to another location like Alternate-Protocol
> does... basically bundling srv information with an http/1 response..
> "here is the answer to your http/1 request and btw over on port 443 we
> speak http2-tls and on port 8080 we speak http2-plaintext".. clients can
> decide whether they want to jump over there right away or overlap some
> more http/1 transactions with the handshake on the other port.. its
> probably not important for http/2 to define exactly what happens other
> than the lifespan of that alternate-protocol announcement.
>
> Case 3b: transform the current connection into an http/2 connection
> (possibly even adding in tls the same way CONNECT does) with http/1
> upgrade roughly like websockets does.
>
> Does that framing seem reasonable?
>
> Does anyone want to make an argument for having both? I'd prefer not to
> at this stage but the question seems worth asking.
>
> In favor of 3a - 1] the results are cached and future connections are
> pure http/2 without bootstrapping them each time. 2] It also can move
> http/2 to a non-port-80 location which alleviates concerns about
> transparent proxies being confused.
>
> In favor of 3b - 1] it doesn't require another connection as the current
> one is transformed in place. 2] it sidesteps issues about caching the
> discovery information of alternate-protocol and its scope and maybe even
> security considerations with it. 3] websockets uses port 80 and I'm not
> overwhelemed with bug reports about unreachable services due to the http
> proxy problem, though the amount of use of websockets is tiny compared
> to http and many websockets applications have comet/etc fallbacks just
> to support browsers without a ws implementation - so the truth here
> might not yet be known.
>
> Mostly I favor 3a because the caching reduces the need for latency
> inducing bootstraps while maximizing the amount of http/2 that is used.
> I don't constantly like redoing that bootstrap. It also dovetails nicely
> with the srv approach as it basically tunnels the srv into http/1.
>
> -Patrick
>
>
>

-- 
Greg Wilkins <[email-masked]>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 1 Oct 2012 19:03:24 +0200

Hi Greg,

> HTTP/2.0 request behind the upgrade request if we are confident of

There are possibilities for this that we discussed in the network-friendly
draft, basically pass a few URIs in a dedicated header field that the server
is free to consider or not.

Willy

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 4 Oct 2012 10:32:39 +0300

Hi there,

I like the Patrick analysis as it tries to cover all the different 
aspects of the issue.

for Case 1 - NPN based, the major issue I see is the lack of progress  
the proposal is doing within the TLS wg
                   (note I may be wrong as I don't follow so closely the 
TLS wg)

for Case 2 - it is interesting to see a proposal based on DNS SRV. is 
that a too optimistic one,
                    also due to the fact that browser are not really 
supporting (is this still true?) SRV at moment?

having said that, I am with Greg and Willy about the fact that Upgrade 
is the way to go,
also because that was the main reason why Upgrade was defined at the time.
However I am open and eager to investigate optimization.

So to summarize I support 3b but open to discuss about 3a

/Sal

-- 
Salvatore Loreto, PhD
www.sloreto.com