Clarify :path format

[daurnimator]

Is a HTTP2 :path allowed to contain a target of 'absolute-form'?
What should the :path (and :authority) contain if making a request through a HTTP2 proxy?

From HTTP1.1 spec:

When making a request to a proxy, other than a CONNECT or server-wide
OPTIONS request (as detailed below), a client MUST send the target
URI in absolute-form as the request-target.

From HTTP2 spec:

The :authority pseudo-header field includes the authority portion of the target URI ([RFC3986], Section 3.2). The authority MUST NOT include the deprecated userinfo subcomponent for http or https schemed URIs.

To ensure that the HTTP/1.1 request line can be reproduced accurately, this pseudo-header field MUST be omitted when translating from an HTTP/1.1 request that has a request target in origin or asterisk form (see [RFC7230], Section 5.3). Clients that generate HTTP/2 requests directly SHOULD use the :authority pseudo-header field instead of the Host header field. An intermediary that converts an HTTP/2 request to HTTP/1.1 MUST create a Host header field if one is not present in a request by copying the value of the :authority pseudo-header field.

The :path pseudo-header field includes the path and query parts of the target URI (the path-absolute production and optionally a '?' character followed by the query production (see Sections 3.3 and 3.4 of [RFC3986]). A request in asterisk form includes the value '*' for the :path pseudo-header field.

Related:

• Fix some of the proxy code paths daurnimator/lua-http#141
• Full request-line sent with http2 curl/curl#3570
• http2-proxy mode issue with Curl --http2-prior-knowledge nghttp2/nghttp2#1304

[mnot]

It seems pretty clear to me; :path contains the path and query parts of the target URI. HTTP/1.1's messaging requirements don't apply to HTTP/2.

[daurnimator]

Would it be correct to say that:

HTTP/1.1 not via a proxy (preferred):

GET /path HTTP/1.1
Host: foo.com

HTTP/1.1 via proxy or not (due to RFC 7230 Section 5.3.2: "To allow for transition to the absolute-form for all requests in some future version of HTTP, a server MUST accept the absolute-form in requests, even though HTTP/1.1 clients will only send them in requests to proxies."):

GET http://foo.com/path HTTP/1.1
Host: fieldignored.com

HTTP/2 either via a proxy or not:

:method GET
:scheme http
:authority foo.com
:path /path

i.e. HTTP/1.1 message request serialization needs to know if it's going via a proxy or not as part of message construction (at least if you want to use the preferred form?)? Whereas HTTP/2 headers are invariant upon use of proxy or not?

[mnot]

I think so.

[martinthomson]

The Host header field in HTTP/2 is only for translation cases.

If you get

GET /path HTTP/1.1
Host: foo.com

You would forward as:

:method GET
:scheme http
:path /path
host foo.com

But if you get the unlikely:

GET http://foo.com/path HTTP/1.1
Host: fieldignored.com

Then you would forward as:

:method GET
:scheme http
:authority foo.com
:path /path
host fieldignored.com

That was the reasoning behind the change. In practice, if :authority is there, that is what servers should use and it should be used where feasible, but there is a potential signal loss if you don't use host when forwarding requests. (There is also a potential security exposure with conflicting values.)

[daurnimator]

That was the reasoning behind the change.

Which change is that?

Is there any other situation that host should be sent? Should the host header be sent in http2 even when it matches :authority?

[martinthomson]

I should have said "design", not "change". Whether you send the host header field depends on whether you are forwarding a request or originating one. No sense in setting it unless you are copying from another request.

[mnot]

Cleaning up old issues.