rfc2224.txt

RFC 的详细文档！

Network Working Group                                        B. Callaghan
Request for Comments: 2224                         Sun Microsystems, Inc.
Category: Informational                                      October 1997

                             NFS URL Scheme

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

Abstract

   A new URL scheme, 'nfs' is defined.  It is used to refer to files and
   directories on NFS servers using the general URL syntax defined in
   RFC 1738, "Uniform Resource Locators (URL)".

   This scheme uses the public filehandle and multi-component lookup
   [RFC2054, RFC2055] to access server data with a minimum of protocol
   overhead.

   The NFS protocol provides access to shared filesystems across
   networks.  It is designed to be machine, operating system, network
   architecture, and transport protocol independent.  The protocol
   currently exists in two versions: version 2 [RFC1094] and version 3
   [RFC1813], both built on ONC RPC [RFC1831] at its associated eXternal
   Data Representation (XDR) [RFC1832] and Binding Protocol [RFC1833].

Table of Contents

      1.    URL Syntax . . . . . . . . . . . . . . . . . . . . . . .  2
      2.    URL Evaluation . . . . . . . . . . . . . . . . . . . . .  2
      3.    Server Connection  . . . . . . . . . . . . . . . . . . .  2
      4.    NFS Version  . . . . . . . . . . . . . . . . . . . . . .  2
      5.    Public Filehandle  . . . . . . . . . . . . . . . . . . .  3
      5.1     NFS Version 2 Public Filehandle  . . . . . . . . . . .  3
      5.2     NFS Version 3 Public Filehandle  . . . . . . . . . . .  3
      6.    Multi-component Lookup . . . . . . . . . . . . . . . . .  3
      6.1     Absolute vs Relative Pathname  . . . . . . . . . . . .  4
      6.2     Symbolic Links . . . . . . . . . . . . . . . . . . . .  5
      7.    Mount Protocol . . . . . . . . . . . . . . . . . . . . .  6
      8.    Bibliography . . . . . . . . . . . . . . . . . . . . . .  7
      9.    Security Considerations  . . . . . . . . . . . . . . . .  8



Callaghan                    Informational                      [Page 1]

RFC 2224                     NFS URL Scheme                 October 1997


      10.   BNF for NFS URL Scheme . . . . . . . . . . . . . . . . .  9
      11.   Acknowledgements . . . . . . . . . . . . . . . . . . . . 10
      12.   Author's Address . . . . . . . . . . . . . . . . . . . . 10
      13.   Full Copyright Statement . . . . . . . . . . . . . . . . 11

1. URL Syntax

   An NFS URL is based on the Common Internet Scheme Syntax described in
   section 3.1 of RFC 1738.  It has the general form:

        nfs://<host>:<port><url-path>

   The ":<port>" part is optional.  If omitted then port 2049 is
   assumed.  The <url-path> is also optional.

   The <url-path> is a hierarchical directory path of the form
   /<directory>/<directory>/<directory>/.../<name>. The <url-path> must
   consist only of characters within the US-ASCII character set.  Within
   a <directory> or <name> component the character "/" is reserved and
   must be encoded as described in Section 2.2 of RFC 1738.  If <url-
   path> is omitted or consists solely of "/", it must default to the
   path ".".

2. URL Evaluation

   A client must evaluate an NFS URL by a method known as WebNFS
   [RFC2054, RFC2055]. This method provides easy passage through
   firewalls and proxy servers, as well as using a minimum number of
   messages.  The WebNFS method is defined for NFS versions 2 and 3. It
   assumes that the server registers on TCP or UDP port 2049 and
   supports the public filehandle and multi-component lookup semantics
   as described in the following sections.

3. Server Connection

   The client must first attempt to create a TCP connection to <host>
   using the <port> specified.  If :<port> is omitted, then port 2049
   will be used.  If the server refuses the TCP connection, then the
   client will use UDP.

4. NFS Version

   The client must first attempt to use NFS version 3.  If the server
   returns an RPC PROG_MISMATCH error then the client must assume that
   NFS version 3 is not supported, and retry the operation with an NFS
   version 2 public filehandle.





Callaghan                    Informational                      [Page 2]

RFC 2224                     NFS URL Scheme                 October 1997


5. Public Filehandle

   NFS filehandles are normally created by the server and used to
   identify uniquely a particular file or directory on the server.  The
   client does not normally create filehandles or have any knowledge of
   the contents of a filehandle.

   The public filehandle is an an exception.  It is an NFS filehandle
   with a reserved value and special semantics that allow an initial
   filehandle to be obtained.  A WebNFS client uses the public
   filehandle as an initial filehandle rather than using the MOUNT
   protocol.  Since NFS version 2 and version 3 have different
   filehandle formats, the public filehandle is defined differently for
   each.

   The public filehandle is a zero filehandle.  For NFS version 2 this
   is a filehandle with 32 zero octets.  A version 3 public filehandle
   has zero length.

5.1 NFS Version 2 Public Filehandle

   A version 2 filehandle is defined in RFC 1094 as an opaque value
   occupying 32 octets.  A version 2 public filehandle has a zero in
   each octet, i.e. all zeros.

    1                                                             32
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2 NFS Version 3 Public Filehandle

   A version 3 filehandle is defined in RFC 1813 as a variable length
   opaque value occupying up to 64 octets.  The length of the filehandle
   is indicated by an integer value contained in a 4 octet value which
   describes the number of valid octets that follow. A version 3 public
   filehandle has a length of zero.

   +-+-+-+-+
   |   0   |
   +-+-+-+-+

6. Multi-component Lookup

   Normally the NFS LOOKUP request (version 2 or 3) takes a directory
   filehandle along with the name of a directory member, and returns the
   filehandle of the directory member.  If a client needs to evaluate a
   pathname that contains a sequence of components, then beginning with



Callaghan                    Informational                      [Page 3]

RFC 2224                     NFS URL Scheme                 October 1997


   the directory filehandle of the first component it must issue a
   series of LOOKUP requests one component at a time.  For instance,
   evaluation of the path  "a/b/c" will generate separate LOOKUP
   requests for each component of the pathname "a", "b", and "c".

   A LOOKUP request that uses the public filehandle can provide a
   pathname containing multiple components.  The server is expected to
   evaluate the entire pathname and return a filehandle for the final
   component.

   For example, rather than evaluate the path "a/b/c" as:

        LOOKUP  FH=0x0  "a"  --->
                             <---  FH=0x1
        LOOKUP  FH=0x1  "b"  --->
                             <---  FH=0x2
        LOOKUP  FH=0x2  "c"  --->
                             <---  FH=0x3

   Relative to the public filehandle these three LOOKUP
   requests can be replaced by a single multi-component
   lookup:

        LOOKUP  FH=0x0  "a/b/c"  --->
                                 <---  FH=0x3

   Multi-component lookup is supported only for LOOKUP requests relative
   to the public filehandle.

   The <url-path> of the NFS URL must be evaluated as a multi-component
   lookup. This implies that the path components are delimited by
   slashes and the characters that make up the path must be in the
   printable US-ASCII character set. Characters not in the "unreserved"
   set (see BNF description below) may be included in pathname
   components but must be escaped.

   If the <url-path> is empty or consists solely of "/", the client must
   send a multi-component lookup for the pathname ".".

6.1 Absolute vs. Relative Pathname

   A multi-component pathname that begins with a slash character is
   considered "absolute" and will be evaluated relative to the server's
   root.  A pathname that does not begin with a slash is "relative" and
   will be evaluated relative to the directory with which the public
   filehandle is associated.





Callaghan                    Informational                      [Page 4]

RFC 2224                     NFS URL Scheme                 October 1997


   Note that the initial "/" that introduces the <url-path> of an NFS
   URL must not be passed to the server for multi-component lookup since
   the pathname is to be evaluated relative to the public filehandle
   directory.  For example, if the public filehandle is associated with
   the server's directory "/a/b/c" then the URL:

        nfs://server/d/e/f

   will be evaluated with a multi-component lookup of the path
   "d/e/f" relative to the server's directory "/a/b/c" while
   the URL:

        nfs://server//a/b/c/d/e/f

   will locate the same file with an absolute multi-component lookup of
   the path "/a/b/c/d/e/f" relative to the server's filesystem root.
   Notice that a double slash is required at the beginning of the path.

   Not all WebNFS servers can support arbitrary use of absolute paths.
   Clearly, the server must not return a filehandle if the path
   identifies a file or directory that is not exported by the server.
   In addition, some servers will not return a filehandle if the path
   names a file or directory in an exported filesystem different from
   the one that is associated with the public filehandle.

6.2 Symbolic Links

   The NFS protocol supports symbolic links, which are the filesystem
   equivalent of a relative URL. If a WebNFS client retrieves a
   filehandle for a symbolic link (as indicated by the file type
   attribute) then it should send a READLINK request to the server to
   retrieve the path comprising the symbolic link.

   This path should then be combined with the URL which referenced the
   symbolic link according to the rules described in RFC 1808.  If the
   relative URL in the symbolic link text is to be resolved successfully
   then it must contain only ASCII characters and conform to the syntax
   described in RFC 1808.  Note that this allows a symbolic link to
   contain an entire URL and it may specify a scheme that is not
   necessarily an NFS URL.

   A symbolic link path that begins with a slash will be evaluated as an
   absolute path relative to the directory associated with the public
   filehandle which may not be the same as the server's system root
   directory.  If symbolic links with absolute paths are to be evaluated
   correctly on both client and server then the public filehandle must
   be associated with the system root directory.




Callaghan                    Informational                      [Page 5]

RFC 2224                     NFS URL Scheme                 October 1997


   For example, if the symbolic link is named by the URL

        nfs://server/a/b

   then the following examples show how a new URL can be
   formed from the symbolic link text:

         c                      = nfs://server/a/c

         c/d                    = nfs://server/a/c/d

         ../c                   = nfs://server/c

         /c/d                   = nfs://server/c/d

         nfs://server2/a/b      = nfs://server2/a/b

7. Mount Protocol

   The NFS URL may have limited use for naming files on servers that do
   not support the public filehandle and multi-component lookup.

   If the server returns an NFS3ERR_STALE, NFS3ERR_INVAL, or
   NFS3ERR_BADHANDLE error in response to the client's use of a public