Re: #421: Mixed Schemes

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 <fielding@gbiv.com> wrote:

> 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
> 
> 

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

Received on Wednesday, 2 April 2014 00:44:05 UTC