Although the following abnormal examples are unlikely to occur in normal practice, all URL parsers should be capable of resolving them consistently. Each example uses the same base as above.
An empty reference resolves to the complete base URL:
<> = <URL:http://a/b/c/d;p?q#f>
Parsers must be careful in handling the case where there are more relative path ".." segments than there are hierarchical levels in the base URL's path. Note that the ".." syntax cannot be used to change the <net_loc> of a URL.
../../../g = <URL:http://a/../g> ../../../../g = <URL:http://a/../../g>
Similarly, parsers must avoid treating "." and ".." as special when they are not complete components of a relative path.
/./g = <URL:http://a/./g> /../g = <URL:http://a/../g> g. = <URL:http://a/b/c/g.> .g = <URL:http://a/b/c/.g> g.. = <URL:http://a/b/c/g..> ..g = <URL:http://a/b/c/..g>
Less likely are cases where the relative URL uses unnecessary or nonsensical forms of the "." and ".." complete path segments.
./../g = <URL:http://a/b/g> ./g/. = <URL:http://a/b/c/g/> g/./h = <URL:http://a/b/c/g/h> g/../h = <URL:http://a/b/c/h>
Finally, some older parsers allow the scheme name to be present in a relative URL if it is the same as the base URL scheme. This is considered to be a loophole in prior specifications of partial URLs  and should be avoided by future parsers.
http:g = <URL:http:g> http: = <URL:http:>