- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Thu, 20 Oct 2016 12:33:55 +0300 (EEST)
- To: HTTP working group mailing list <ietf-http-wg@w3.org>
- CC: Kazuho Oku <kazuhooku@gmail.com>, Tom Bergan <tombergan@chromium.org>, Ilari Liusvaara <ilariliusvaara@welho.com>, Van Catha <vans554@gmail.com>
> This could be the case for any HTTP/2 gateway that translates incoming > requests to HTTP/1, that does not reject unknown schemes. And whether > such gateway needs to reject schemes that do not match to the > request-response model of HTTP seems to be vague in reading RFC 7540. > Section 8.1.2.3 states that: > > ":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. > > My interpretation of this paragraph would be that it is permitted for > an HTTP/2 intermediary to transmit requests with schemes other than > "http" or "https", expecting that an upstream server would process the > request according to the scheme, considering the fact that (per my > understanding) such action is permitted in HTTP/1.1. Yes. HTTP/2 explicitly uses HTTP/1.1 semantic. 8. HTTP Message Exchanges https://tools.ietf.org/html/rfc7540#section-8 | Thus, the specification and requirements of HTTP/1.1 Semantics and | Content [RFC7231], Conditional Requests [RFC7232], Range Requests | [RFC7233], Caching [RFC7234], and Authentication [RFC7235] are | applicable to HTTP/2. Selected portions of HTTP/1.1 Message Syntax | and Routing [RFC7230], such as the HTTP and HTTPS URI schemes, are | also applicable in HTTP/2, but the expression of those semantics for | this protocol are defined in the sections below. 3.1. Client Handshake Request https://tools.ietf.org/html/draft-svirid-websocket2-over-http2-00#section-3.1 | 3.1. Client Handshake Request | | The client MUST use the :method GET. | | The client MUST send a sec-ws2-version header that MUST specify the | websocket2 version being used. | | The client MAY send a sec-ws2-compression header that advertises the | compression methods the client supports. Valid key value pairs | include: ↡ | The client MUST NOT set the END_STREAM flag when sending the headers. Note however that this apply: 4.3.1. GET https://tools.ietf.org/html/rfc7231#section-4.3.1 | A payload within a GET request message has no defined semantics; | sending a payload body on a GET request might cause some existing | implementations to reject the request. | | The response to a GET request is cacheable; a cache MAY use it to | satisfy subsequent GET and HEAD requests unless otherwise indicated | by the Cache-Control header field (Section 5.2 of [RFC7234]). Changing of scheme does not change semantic of methods. 2. Resources https://tools.ietf.org/html/rfc7231#section-2 | One design goal of HTTP is to separate resource identification from | request semantics, which is made possible by vesting the request | semantics in the request method (Section 4) and a few | request-modifying header fields (Section 5). If there is a conflict | between the method semantics and any semantic implied by the URI | itself, as described in Section 4.2.1, the method semantics take | precedence. ( scheme is part of URI ) 2.7. Uniform Resource Identifiers https://tools.ietf.org/html/rfc7230#section-2.7 | Uniform Resource Identifiers (URIs) [RFC3986] are used throughout | HTTP as the means for identifying resources (Section 2 of [RFC7231]). | URI references are used to target requests, indicate redirects, and | define relationships. / Kari Hurtta
Received on Thursday, 20 October 2016 09:34:31 UTC