Re: p1: Upgrade ordering (possible HTTP/2 impact)

[Willy Tarreau <[e-mail]>]

On Sat, Apr 20, 2013 at 05:13:09PM +1000, Mark Nottingham wrote:
> 
> On 20/04/2013, at 5:10 PM, Willy Tarreau <[e-mail]> wrote:
> 
> > On Sat, Apr 20, 2013 at 02:07:57PM +1000, Mark Nottingham wrote:
> >> p1 section 6.7 defines the Upgrade header, but no where does it say anything
> >> about relative preference.
> >> 
> >> Should we define (or at least allow) for the ordering to be semantically
> >> significant? It seems to me that if we end up using this, and there are a few
> >> different variants of HTTP/2 (e.g., "normal" vs "mobile"), it'd be nice to
> >> rely on ordering here.
> > 
> > Indeed it could be quite useful! RFC2817 does not suggest anything concerning
> > multiple values in the Upgrade header field for the request message, it only
> > suggests that the response describes the protocol stack (eg: TLS/1.0, HTTP/1.1).
> > 
> > So I'm wondering if it would not be a abit awkward to have a different
> > definition of this header field depending on the direction. Some more thinking
> > is needed on this I suppose.
> 
> 
> We're already there; in the current form, it describes the protocols the
> client can upgrade to in requests, whereas in 101 responses it describes the
> (single) protocol the server *is* upgrading to.

OK so your suggestion makes pretty much sense then, we could probably state
that servers should pick the first one they support and that clients supporting
multiple protocols order them by preference ?

Willy