Connected: An Internet Encyclopedia
RFC 1630 - 4.1.4. Partial (relative) form

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1630
Up: 4. Recommendations
Up: 4.1. URI syntax
Prev: 4.1.3. Encoding reserved characters
Next: 4.1.5. Fragment-id

### 4.1.4. Partial (relative) form

Within a object whose URI is well defined, the URI of another object may be given in abbreviated form, where parts of the two URIs are the same. This allows objects within a group to refer to each other without requiring the space for a complete reference, and it incidentally allows the group of objects to be moved without changing any references. It must be emphasized that when a reference is passed in anything other than a well controlled context, the full form must always be used.

In the World-Wide Web applications, the context URI is that of the document or object containing a reference. In this case partial URIs can be generated in virtual objects or stored in real objects, without the need for dramatic change if the higher-order parts of a hierarchical naming system are modified. Apart from terseness, this gives greater robustness to practical systems, by enabling information hiding between system components.

The partial form relies on a property of the URI syntax that certain characters ("/") and certain path elements ("..", ".") have a significance reserved for representing a hierarchical space, and must be recognized as such by both clients and servers.

A partial form can be distinguished from an absolute form in that the latter must have a colon and that colon must occur before any slash characters. Systems not requiring partial forms should not use any unencoded slashes in their naming schemes. If they do, absolute URIs will still work, but confusion may result. (See note on Gopher below.)

The rules for the use of a partial name relative to the URI of the context are:

If the scheme parts are different, the whole absolute URI must be given. Otherwise, the scheme is omitted, and:

If the partial URI starts with a non-zero number of consecutive slashes, then everything from the context URI up to (but not including) the first occurrence of exactly the same number of consecutive slashes which has no greater number of consecutive slashes anywhere to the right of it is taken to be the same and so prepended to the partial URL to form the full URL. Otherwise:

The last part of the path of the context URI (anything following the rightmost slash) is removed, and the given partial URI appended in its place, and then:

Within the result, all occurrences of "xxx/../" or "/." are recursively removed, where xxx, ".." and "." are complete path elements.

Note: Trailing slashes

If a path of the context locator ends in slash, partial URIs are treated differently to the URI with the same path but without a trailing slash. The trailing slash indicates a void segment of the path.

Note: Gopher

The gopher system does not have the concept of relative URIs, and the gopher community currently allows / as data characters in gopher URIs without escaping them to %2F. Relative forms may not in general be used for documents served by gopher servers. If they are used, then WWW software assumes, normally correctly, that in fact they do have hierarchical significance despite the specifications. The use of HTTP rather than gopher protocol is however recommended.

#### Examples

In the context of URI

                            magic://a/b/c//d/e/f

the partial URIs would expand as follows:

       g                       magic://a/b/c//d/e/g

       /g                      magic://a/g

       //g                     magic://g

       ../g                    magic://a/b/c//d/g

       g:h                     g:h

and in the context of the URI

                               magic://a/b/c//d/e/

the results would be exactly the same.

Next: 4.1.5. Fragment-id

Connected: An Internet Encyclopedia
RFC 1630 - 4.1.4. Partial (relative) form