On Fri, Jun 10, 2016 at 4:03 AM, Stefan Eissing < [email protected]> wrote:
> Withdrawn the proposal in r1747668 after reading the comment from Roy > again. > Let's look at what Roy said... that httpd's implementation of HTTP/1.1 may choose to honor a Connection-Upgrade request header of h2, or http/2, or any other values we choose, because we are bound by the HTTP/1.1 RFC, not some arbitrary choice by the HTTP/2 RFC. Wrong RFC to change HTTP/1.1 behavior, these headers are only to be used in conformance with https://tools.ietf.org/html/rfc7230#section-6.7 So the http/1.1 Upgrade response header must mirror what the server will honor for the Connection: Upgrade http/1.1 -> {something else} Upgrade request value. My initial response is still correct, *if* httpd is willing to honor Upgrade: h2 or Upgrade: http/2 request header values, then it is appropriate to offer these in the response headers. And as Roy says, we *can* do so irrespective of any claims within https://tools.ietf.org/html/rfc7540#section-3.2 because that is not the binding specification during the http/1.1 phase of the request. https://tools.ietf.org/html/rfc7540#page-78 registered the h2c token for the Upgrade token, HTTP (including HTTP/2) was already registered. However, no token 'h2' is registered. That doesn't prevent us or others from sending and respecting other values, SSL/ was long considered valid, but I don't see where 'h2' should be used in the context of the 'Upgrade' header. http://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml For right now, 'h2' should not be presented if 'h2' will not be honored, IMHO.
