rfc1808.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   Step 7: The resulting URL components, including any inherited from
           the base URL, are recombined to give the absolute form of
           the embedded URL.

   Parameters, regardless of their purpose, do not form a part of the
   URL path and thus do not affect the resolving of relative paths.  In
   particular, the presence or absence of the ";type=d" parameter on an
   ftp URL does not affect the interpretation of paths relative to that
   URL.  Fragment identifiers are only inherited from the base URL when
   the entire embedded URL is empty.







Fielding                    Standards Track                    [Page 11]

RFC 1808           Relative Uniform Resource Locators          June 1995


   The above algorithm is intended to provide an example by which the
   output of implementations can be tested -- implementation of the
   algorithm itself is not required.  For example, some systems may find
   it more efficient to implement Step 6 as a pair of segment stacks
   being merged, rather than as a series of string pattern matches.

5.  Examples and Recommended Practice

   Within an object with a well-defined base URL of

      Base: <URL:http://a/b/c/d;p?q#f>

   the relative URLs would be resolved as follows:

5.1.  Normal Examples

      g:h        = <URL:g:h>
      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/g>
      //g        = <URL:http://g>
      ?y         = <URL:http://a/b/c/d;p?y>
      g?y        = <URL:http://a/b/c/g?y>
      g?y/./x    = <URL:http://a/b/c/g?y/./x>
      #s         = <URL:http://a/b/c/d;p?q#s>
      g#s        = <URL:http://a/b/c/g#s>
      g#s/./x    = <URL:http://a/b/c/g#s/./x>
      g?y#s      = <URL:http://a/b/c/g?y#s>
      ;x         = <URL:http://a/b/c/d;x>
      g;x        = <URL:http://a/b/c/g;x>
      g;x?y#s    = <URL:http://a/b/c/g;x?y#s>
      .          = <URL:http://a/b/c/>
      ./         = <URL:http://a/b/c/>
      ..         = <URL:http://a/b/>
      ../        = <URL:http://a/b/>
      ../g       = <URL:http://a/b/g>
      ../..      = <URL:http://a/>
      ../../     = <URL:http://a/>
      ../../g    = <URL:http://a/g>

5.2.  Abnormal Examples

   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.





Fielding                    Standards Track                    [Page 12]

RFC 1808           Relative Uniform Resource Locators          June 1995


   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
   [1] and should be avoided by future parsers.

      http:g        = <URL:http:g>
      http:         = <URL:http:>

5.3.  Recommended Practice

   Authors should be aware that path names which contain a colon ":"
   character cannot be used as the first component of a relative URL
   path (e.g., "this:that") because they will likely be mistaken for a
   scheme name.  It is therefore necessary to precede such cases with
   other components (e.g., "./this:that"), or to escape the colon
   character (e.g., "this%3Athat"), in order for them to be correctly
   parsed.  The former solution is preferred because it does not affect
   the absolute form of the URL.



Fielding                    Standards Track                    [Page 13]

RFC 1808           Relative Uniform Resource Locators          June 1995


   There is an ambiguity in the semantics for the ftp URL scheme
   regarding the use of a trailing slash ("/") character and/or a
   parameter ";type=d" to indicate a resource that is an ftp directory.
   If the result of retrieving that directory includes embedded relative
   URLs, it is necessary that the base URL path for that result include
   a trailing slash.  For this reason, we recommend that the ";type=d"
   parameter value not be used within contexts that allow relative URLs.

6.  Security Considerations

   There are no security considerations in the use or parsing of
   relative URLs.  However, once a relative URL has been resolved to its
   absolute form, the same security considerations apply as those
   described in RFC 1738 [2].

7.  Acknowledgements

   This work is derived from concepts introduced by Tim Berners-Lee and
   the World-Wide Web global information initiative.  Relative URLs are
   described as "Partial URLs" in RFC 1630 [1].  That description was
   expanded for inclusion as an appendix for an early draft of RFC 1738,
   "Uniform Resource Locators (URL)" [2].  However, after further
   discussion, the URI-WG decided to specify Relative URLs separately
   from the primary URL draft.

   This document is intended to fulfill the recommendations for Internet
   Resource Locators as stated in [6].  It has benefited greatly from
   the comments of all those participating in the URI-WG.  Particular
   thanks go to Larry Masinter, Michael A. Dolan, Guido van Rossum, Dave
   Kristol, David Robinson, and Brad Barber for identifying
   problems/deficiencies in earlier drafts.

8.  References

   [1] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
       Unifying Syntax for the Expression of Names and Addresses of
       Objects on the Network as used in the World-Wide Web", RFC 1630,
       CERN, June 1994.

   [2] Berners-Lee, T., Masinter, L., and M. McCahill, Editors, "Uniform
       Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation,
       University of Minnesota, December 1994.

   [3] Berners-Lee T., and D. Connolly, "HyperText Markup Language
       Specification -- 2.0", Work in Progress, MIT, HaL Computer
       Systems, February 1995.
       <URL:http://www.ics.uci.edu/pub/ietf/html/>




Fielding                    Standards Track                    [Page 14]

RFC 1808           Relative Uniform Resource Locators          June 1995


   [4] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
       Extensions): Mechanisms for Specifying and Describing the Format
       of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,
       September 1993.

   [5] Crocker, D., "Standard for the Format of ARPA Internet Text
       Messages", STD 11, RFC 822, UDEL, August 1982.

   [6] Kunze, J., "Functional Recommendations for Internet Resource
       Locators", RFC 1736, IS&T, UC Berkeley, February 1995.

9.  Author's Address

   Roy T. Fielding
   Department of Information and Computer Science
   University of California
   Irvine, CA  92717-3425
   U.S.A.

   Tel: [phone]
   Fax: [phone]
   EMail: [e-mail]

10.  Appendix - Embedding the Base URL in HTML documents

   It is useful to consider an example of how the base URL of a document
   can be embedded within the document's content.  In this appendix, we
   describe how documents written in the Hypertext Markup Language
   (HTML) [3] can include an embedded base URL.  This appendix does not
   form a part of the relative URL specification and should not be
   considered as anything more than a descriptive example.

   HTML defines a special element "BASE" which, when present in the
   "HEAD" portion of a document, signals that the parser should use the
   BASE element's "HREF" attribute as the base URL for resolving any
   relative URLs.  The "HREF" attribute must be an absolute URL.  Note
   that, in HTML, element and attribute names are case-insensitive.  For
   example:

      <!doctype html public "-//IETF//DTD HTML//EN">
      <HTML><HEAD>
      <TITLE>An example HTML document</TITLE>
      <BASE href="http://www.ics.uci.edu/Test/a/b/c">
      </HEAD><BODY>
      ... <A href="../x">a hypertext anchor</A> ...
      </BODY></HTML>





Fielding                    Standards Track                    [Page 15]

RFC 1808           Relative Uniform Resource Locators          June 1995


   A parser reading the example document should interpret the given
   relative URL "../x" as representing the absolute URL

      <URL:http://www.ics.uci.edu/Test/a/x>

   regardless of the context in which the example document was obtained.













































Fielding                    Standards Track                    [Page 16]