Subject: Re: #421: Mixed Schemes

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Apr 2014 11:43:39 +1100

Roy,

Is the specific problem you're pointing out to do with the phrase "the semantics of requests for non-HTTP schemes is not defined in this document"?

The text you mention is quite brief, and doesn't define any requirements for handling other schemes (or not); it's just a very high-level state of intent regarding the protocol's capabilities -- not a constraint.

Cheers,

On 1 Apr 2014, at 1:20 pm, Roy T. Fielding <[email-masked]> wrote:

> On Mar 31, 2014, at 3:37 PM, Martin Thomson wrote:
> 
>> On 30 March 2014 00:34, Mark Nottingham <[email-masked]> 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
> 
> 

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 2 Apr 2014 05:57:37 -0700

> The text you mention is quite brief, and doesn't define any requirements for handling other schemes (or not); it's just a very high-level state of intent regarding the protocol's capabilities -- no…

The whole paragraph seems confused to me.  The semantics of a request
are defined by the request method and header fields.  The URI specifically
has no request semantics.  The comment assumes that http and https are
the only relevant schemes, which just plain ignores the proxy use case
described in HTTP/1.1.  1.1 doesn't need special requirements for that,
since support for non-http(s) schemes is inherent to the interface
provided by HTTP for absolute URIs.

....Roy

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Apr 2014 09:18:58 -0700

> provided by HTTP for absolute URIs.

Here's what I am going to propose.  I've had trouble getting this
right in my head, so feel free to bash on the specifics...

"""
":scheme" is not restricted to "http:" and "https:" schemed URIs.  A
proxy or gateway can translate requests for non-HTTP schemes, enabling
the use of HTTP to interact with non-HTTP services.
"""

I'll concede that the URI decomposition in HTTP/2 is perhaps less than
ideal for dealing with non-HTTP URIs, but since the components map
directly to the 3986 concepts, I think that we'll get away with it.
URNs, for instance, can just use :scheme and :path.

BTW, hiding this critical text in the introduction of part 1 was
canny.  I went looking in a lot of places, but didn't think to look
there.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 2 Apr 2014 10:29:58 -0700

> URNs, for instance, can just use :scheme and :path.

Looks good, except the colon is not part of the scheme name.  Thanks.

> canny.  I went looking in a lot of places, but didn't think to look

Yeah, well ... I think at one point we were planning to have a more
extensive description of all the wonderful things a proxy can do,
but we ended up just defining the purpose of each field instead.

....Roy

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Apr 2014 10:39:18 -0700

> but we ended up just defining the purpose of each field instead.

Which is adequate, if not ideal.  Honestly, if you were to
exhaustively enumerate what was possible, a -bis in 7 years would turn
into 70.

Maybe I should read the introductory section again.