request target is h1-specific #259

Activity

1. mnot

   added

   semantics

   caching

   on Oct 1, 2019
2. mnot commented on Oct 1, 2019

   

   mnot

   on Oct 1, 2019

   MemberAuthor

   More actions

   Also some instances of "target URI"
3. mnot

   self-assigned this

   on Feb 2, 2020
4. mnot commented on Feb 3, 2020

   

   mnot

   on Feb 3, 2020

   MemberAuthor

   More actions

   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
5. mnot

   assigned

   royfielding

   on Feb 3, 2020
6. reschke commented on Feb 3, 2020

   

   reschke

   on Feb 3, 2020

   Contributor

   More actions

   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.
7. mnot

   added a commit that references this issue on Feb 7, 2020

   map request target to target URI/resource

   ...

   35cf535
8. mnot

   unassigned

   royfielding

   on Feb 7, 2020
9. mnot commented on Mar 19, 2020

   

   mnot

   on Mar 19, 2020

   MemberAuthor

   More actions

   Expanding to include status-line and request-line.
10. mnot

    changed the title [-]request target is h1-specific[/-] [+]request target / status line / request line are h1-specific[/+] on Mar 19, 2020
11. mnot commented on Mar 19, 2020

    

    mnot

    on Mar 19, 2020

    MemberAuthor

    More actions

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

    changed the title [-]request target / status line / request line are h1-specific[/-] [+]request target is h1-specific[/+] on Mar 19, 2020
13. mnot

    added

    has-proposal

    on Mar 19, 2020
14. reschke

    added 9 commits that reference this issue on Apr 27, 2020

    fix change log section title (#259)

    9cd9474

    fix change log (#259)

    c3c40d0

    fix change log section title (#259)

    44432c6

    re-add missing closing brackets (#259)

    a0ee8e1

    restore indentation (#259)

    3c883f8

    sort change log (#259)

    d260c55

    push note into <aside> and move index entry (#259)

    02f7dc5

    Adjust anchor names (#259)

    0b25637

    fix one leftover of "effective request URI" (#259)

    5034a99
15. mnot

    closed this as completedon May 5, 2020