-
Notifications
You must be signed in to change notification settings - Fork 86
Path parameters
RFC 1738 URL
Obsoleted by:
Updated by:
- 1808 relative URI see below
- 2368 mailto (N/A)
- 2396 URI:generic see below
- 3986 URI:generic see below (current)
- 6196 mailto (N/A)
- 6270 tn3270 (N/A)
- 8089 file (N/A)
FTP URLs are defined as:
<cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode>
No "/../" or "/./" sequences.
RFC 1808 Relative URLs
Obsoleted by:
- 3986 URI:generic see below (current)
Updated by:
<scheme>://<net_loc>/<path>;<params>?<query>#<fragment>
params = param *( ";" param )
param = *( pchar | "/" )
Similarly, RFC 1738 allows the reserved character semicolon (";") within an http path segment, but does not define its semantics; the correct semantics are as defined by this document for <params>.
2.4.5. Parsing the Parameters
If the parse string contains a semicolon ";" character, then the substring after the first (left-most) semicolon ";" and up to the end of the parse string is the parameters (<params>). If the semicolon is the last character, or no semicolon is present, then <params> is empty. The matched substring, including the semicolon character, is removed from the parse string before continuing.
4 Discusses removal of "/./" and "/../" when resolving relative URLs
Parameters, regardless of their purpose, do not form a part of the URL path and thus do not affect the resolving of relative paths.
5
Examples show base http://a/b/c/d;p?q#f and relative g resolving to http://a/b/c/g (drops parameter, query string and fragment)
Obsoleted by:
3
<scheme>://<authority><path>?<query>
path = [ abs_path | opaque_part ]
abs_path = "/" path_segments
path_segments = segment *( "/" segment )
segment = *pchar *( ";" param )
param = *pchar
Each path segment may include a sequence of parameters, indicated by the semicolon ";" character. The parameters are not significant to the parsing of relative references.
...certain path components ("." and "..") have a special meaning when, and only when, interpreting a relative path.
Examples show base http://a/b/c/d;p?q and relative g resolving to http://a/b/c/g (drops parameter and query string)
Examples show base http://a/b/c/d;p?q and relative g;x=1/./y resolving to http://a/b/c/g;x=1/y (drops parameter and query string)
RFC 3986 URI:generic (current)
Updated by:
"/../" and "/./" are no longer limited to relative URIs.
URI producing applications often use the reserved characters allowed in a segment to delimit scheme-specific or dereference-handler-specific subcomponents. For example, the semicolon (";") and equals ("=") reserved characters are often used to delimit parameters and parameter values applicable to that segment. The comma (",") reserved character is often used for similar purposes. For example, one URI producer might use a segment such as "name;v=1.1" to indicate a reference to version 1.1 of "name", whereas another might use a segment such as "name,1.1" to indicate the same. Parameter types may be defined by scheme-specific semantics, but in most cases the syntax of a parameter is specific to the implementation of the URI's dereferencing algorithm.
Examples show base http://a/b/c/d;p?q and relative g resolving to http://a/b/c/g (drops parameter and query string)
Examples show base http://a/b/c/d;p?q and relative g;x=1/./y resolving to http://a/b/c/g;x=1/y (drops parameter and query string)
The complete path segments "." and ".." are intended only for use within relative references (Section 4.1) and are removed as part of the reference resolution process (Section 5.2). However, some deployed implementations incorrectly assume that reference resolution is not necessary when the reference is already a URI and thus fail to remove dot-segments when they occur in non-relative paths. URI normalizers should remove dot-segments by applying the remove_dot_segments algorithm to the path, as described in Section 5.2.4.