HTTP Effective Request URI
The effective request URI is the URI of the resource being acted on in an HTTP request. For historical reasons (see the Host header), it is usually broken up into two or more parts, and must be reconstructed by the server.
Making Requests (HTTP/1)
HTTP/1 splits the request URI into two lines, the request-line, and the Host header. The Host header should come immediately after the request-line, for performance purposes, since they are used together.
HTTP/1 requests in origin-form
Split the URI into the scheme, authority, and request-URI.
- The scheme is not included in the HTTP request, though it will influence which interface, which usually accepts HTTP requests exclusively from one scheme.
- The authority is written into the Host header. If there is no authority part of the URI, write a blank Host header.
- The request-URI is written in the first line of the HTTP request. It includes everything after the authority, starting with a leading
/, but excluding the fragment.
HTTP/1 requests in absolute-form
This form is typically only used when addressing proxies, but technically should work for any compatible HTTP server. Use the entire request URI in the request-line, also write the authority to the Host header.
Making Requests (HTTP/2)
HTTP/2 splits apart the request-URI into several components for performance purposes, due to how HTTP header compression functions, and the fact that the scheme and authority does not typically change between requests.
Reading requests (HTTP/1)
HTTP/1 allows four forms for making requests:
request-target = origin-form
/ absolute-form
/ authority-form
/ asterisk-form
origin-form = absolute-path [ "?" query ]
These may be parsed as follows:
- If the first character is the slash
/, parse as origin-form. - If the method is CONNECT, parse as authority-form
- If the method is OPTIONS and the string is a single character
*, parse as asterisk-form - If the string contains a colon (not as the first character), parse as absolute-form.
- Otherwise, emit an error.
From origin-form
To reconstruct from origin-form, three pieces of data are required: the scheme, the authority, and the path.
The scheme must be detected based on how the request was made. This is typically straightforward: If the request came into port 80 over TCP, the request-URI scheme is probably http:, and if the request came into port 443 over TLS (over TCP), the request-URI scheme is probably https:.
If the server is configured to assume a fixed authority, use that. If the Host header is available, use that. HTTP/1.0 does not require the Host header, in which case the server may either opt to detect the Host, or return an error.
After validating, can be constructed from the template {scheme}:{slash}{authority}{path}, where:
- {scheme}
- the detected scheme
- {slash}
- two slashes
//ifauthorityis non-empty, or an empty string otherwise - {authority}
- value from the
Hostheader - {path}
- value from the request-URI
From absolute-form
The request-URI is what is found on the request-line.
Verify the syntax is a valid URI, and return 400 (Client Error) if not.
Verify the host and port (if any) components match the Host header, and return 400 (Client Error) if not.
If the server is configured to use a fixed scheme and authority, replace the scheme and authority in the request-line with the configured scheme and authority.
Other forms
The other forms are special cases.
If the asterisk-form is used with a method besides OPTIONS, emit 405 (Method Not Allowed).
If the authority-form is used with a method besides CONNECT, emit 405 (Method Not Allowed).
If there's no need to implement these, return 501 (Not Implemented).