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