request target is h1-specific

[mnot]

Semantics and caching contain many uses of "request target" and request-target. This is a term that's specific to h1's wire format; it should be specified in a way that is not version-specific.

I think that in almost every case, "effective request URI" is the term we want to use.

There are a few places where details are discussed (e.g., Host); I think these should be moved into h1-messaging.

[mnot]

Also some instances of "target URI"

[mnot]

Going through Semantics:

5.1 defines "target resource" and "target URI" pretty well, and they (mostly target resource) are used consistently and appropriately throughout the spec, with these exceptions:

1.

A server listens on a connection for a request, parses each message received, interprets the message semantics in relation to the identified request target

s/the identified request target/its target resource/

2.5.3.

When not being used in absolute form as the request target of an OPTIONS request

Not sure, due to weirdness around OPTIONS.

2.5.4.

A sender must not generate the userinfo subcomponent (and its "@" delimiter) when an "http" or "https" URI reference is generated within a message as a request target or field value.

s/request target/target URI/

3.3.

For example, an origin server that publishes very long URI references to its own resources needs to be able to parse and process those same references when received as a request target.

s/request target/target URI/

5.4.

For example, the request might have been misdirected, deliberately or accidentally, such that the information within a received request-target or Host header field differs from the host or port upon which the connection has been made.

s/request-target/target URI/

It would also be good to revisit why we need an effective request URI that's separate from the concept of a target URI... I suspect all instances of the former could be replaced with the latter, and this section's content folded into 5.1 as appropriate.

5.6.2.

If a proxy receives a request-target with a host name that is not a fully qualified domain name, it may add its own domain to the host name it received when forwarding the request. A proxy must not change the host name if the request-target contains a fully qualified domain name.

s/request-target/target URI/g

A proxy must not modify the "absolute-path" and "query" parts of the received request-target when forwarding it to the next inbound server, except as noted above to replace an empty path with "/" or "*".

s/request-target/target URI/

7.6.3.

The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target

s/request-target/target URI/

A client sending a CONNECT request must send the authority form of request-target (Section 3.2 of [Messaging]); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.

This seems specific to 1.1...

7.3.7.

An OPTIONS request with an asterisk ("*") as the request-target (Section 3.2 of [Messaging]) applies to the server in general rather than to a specific resource.

If the request-target is not an asterisk, the OPTIONS request applies to the options that are available when communicating with the target resource.

Not sure here, because of the weirdness around OPTIONS.

8.6.2.

An intermediary should not modify or delete the Referer header field when the field value shares the same scheme and host as the request target.

s/request-target/target URI/

9.4.

Redirection that offers a choice of matching resources, each capable of representing the original request target, as in the 300 (Multiple Choices) status code.

s/request target/target resource/

9.5.15

The 414 (URI Too Long) status code indicates that the server is refusing to service the request because the request-target (Section 3.2 of [Messaging]) is longer than the server is willing to interpret.

s/request-target/target URI/, and change the reference to 5.1.

10.1.2.

If the Location value provided in a 3xx (Redirection) response does not have a fragment component, a user agent must process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target

s/request-target/target URI/

10.1.4.

The "Vary" header field in a response describes what parts of a request message, aside from the method, Host header field, and request target, might influence the origin server's process for selecting and representing this response.

s/request-target/target URI/

An origin server should send a Vary header field when its algorithm for selecting a representation varies based on aspects of the request message other than the method and request target

s/request-target/target URI/

11.4.

An attacker could construct any of the request data elements (method, request-target, header fields, or body) to contain data that might be misinterpreted as a command, code, or query when passed through a command invocation, language interpreter, or database interface.

For example, SQL injection is a common attack wherein additional query language is inserted within some part of the request-target or header fields (e.g., Host, Referer, etc.).

s/request-target/target URI/g

11.5.

A server can reject a message that has a request-target that is too long (Section 9.5.15) or a request payload that is too large (Section 9.5.14).

s/request-target/target URI/

11.8.

Authors of services ought to avoid GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties.

s/request-target/target URI/g

[reschke]

if we define "target URI" as the same thing as "effective request URI", we can indeed simplify the text. I would argue that we should still keep the definition somewhere (or explain clearly what we replaced it with), so downstream specs aren't negatively affected.

[mnot]

Expanding to include status-line and request-line.

[mnot]

Actually, no - that will require a bit more surgery, I think; punting to a separate issue.