W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: #421: Mixed Schemes

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 2 Apr 2014 10:29:58 -0700
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <58A674E0-B0F2-4EB2-AF2F-E1C1DDE4A717@gbiv.com>
To: Martin Thomson <martin.thomson@gmail.com>
On Apr 2, 2014, at 9:18 AM, Martin Thomson wrote:

> On 2 April 2014 05:57, Roy T. Fielding <fielding@gbiv.com> wrote:
>> 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.
> 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.

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

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

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.

Received on Wednesday, 2 April 2014 17:30:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:29 UTC