Re: #421: Mixed Schemes

On Mar 31, 2014, at 3:37 PM, Martin Thomson wrote:

> On 30 March 2014 00:34, Mark Nottingham <mnot@mnot.net> wrote:
>> 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.
> 
> 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.

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

Received on Tuesday, 1 April 2014 02:20:30 UTC