Subject: #421: Mixed Schemes

From: Mark Nottingham <[email-masked]>
Date: Sun, 30 Mar 2014 18:34:38 +1100

<https://github.com/http2/http2-spec/issues/421>

My recollection of discussion here was that in principle, people aren't against mixed schemes *in general* (as there are some sensible use cases for them), but that specific schemes in particular situations do bring up various problems.

Since this issue is about noting that it's possible -- NOT permitting it in any circumstance -- I think we can instruct the editor to note this without being too expansive.

Make sense?

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Mar 2014 15:37:09 -0700

> Since this issue is about noting that it's possible -- NOT permitting it in any circumstance -- I think we can instruct the editor to note this without being too expansive.

Proposed text (in discussion of the :scheme pseudo-header field):

      This header field is primarily intended to allow a server to
      distinguish between "http:" or "https:" URIs in requests.  HTTP/2
      doesn't prevent clients from making requests for other URI
      schemes, but the semantics of requests for non-HTTP schemes is not
      defined in this document.

I could reference the new Not Authoritative status code, but I think
that this is sufficient.  This just marks this as "undefined
behaviour"; others can define semantics (and they already do), but we
don't need to do anything more than note the possibility here.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 31 Mar 2014 19:20:06 -0700

> don't need to do anything more than note the possibility here.

That is not consistent with HTTP/1.1.  The intro of p1 says:

  HTTP is also designed for use as an intermediation protocol for
  translating communication to and from non-HTTP information systems.
  HTTP proxies and gateways can provide access to alternative
  information services by translating their diverse protocols into
  a hypertext format that can be viewed and manipulated by clients
  in the same way as HTTP services.

and that is reiterated in the definition of proxy.  IOW, the
semantics of the request are the same as for HTTP -- the
recipient (proxy) is responsible for mapping the inbound
resource protocol/whatever to HTTP semantics.

....Roy