- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 2 Apr 2014 10:29:58 -0700
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
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. ....Roy
Received on Wednesday, 2 April 2014 17:30:21 UTC