Interface HttpURI

All Known Implementing Classes:
HttpURI.Immutable, HttpURI.Mutable

public interface HttpURI
Http URI. Both HttpURI.Mutable and HttpURI.Immutable implementations are available via the static methods such as build() and from(String). A URI such as http://user@host:port/path;param1/%2e/info;param2?query#fragment is split into the following optional elements:

The path part of the URI is provided in both raw form (getPath()) and decoded form (getDecodedPath()), which has: path parameters removed, percent encoded characters expanded and relative segments resolved. This approach is somewhat contrary to RFC3986 which no longer defines path parameters (removed after RFC2396) and specifies that relative segment normalization should take place before percent encoded character expansion. A literal interpretation of the RFC can result in URI paths with ambiguities when viewed as strings. For example, a URI of /foo%2f..%2fbar is technically a single segment of "/foo/../bar", but could easily be misinterpreted as 3 segments resolving to "/bar" by a file system.

Thus this class avoid and/or detects such ambiguities. Furthermore, by decoding characters and removing parameters before relative path normalization, ambiguous paths will be resolved in such a way to be non-standard-but-non-ambiguous to down stream interpretation of the decoded path string. The violations are recorded and available by API such as hasAmbiguousSegment() so that requests containing them may be rejected in case the non-standard-but-non-ambiguous interpretations are not satisfactory for a given compliance configuration.

Implementations that wish to process ambiguous URI paths must configure the compliance modes to accept them and then perform their own decoding of getPath().

If there are multiple path parameters, only the last one is returned by getParam().