rfc2054.txt

RFC 的详细文档！

   component. Both canonical (slash-separated) and server native
   pathnames are supported.

   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.

6.1 Canonical Path vs. Native Path

   If the pathname in a multi-component LOOKUP request begins with an
   ASCII character, then it must be a canonical path.  A canonical path
   is a hierarchically-related, slash-separated sequence of components,
   <directory>/<directory>/.../<name>.  Occurrences of the "/" character
   within a component must be escaped using the escape code %2f.  Non-
   ascii characters within components must also be escaped using the "%"
   character to introduce a two digit hexadecimal code. Occurrences of
   the "%" character that do not introduce an encoded character must
   themselves be encoded with %25.





Callaghan                    Informational                      [Page 6]

RFC 2054              WebNFS Client Specification           October 1996


   If the first character of the path is a slash, then the canonical
   path will be evaluated relative to the server's root directory.  If
   the first character is not a slash, then the path will be evaluated
   relative to the directory with which the public filehandle is
   associated.

   Not all WebNFS servers can support arbitrary use of absolute paths.
   Clearly, the server cannot 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.

   If the first character of the path is 0x80 (non-ascii) then the
   following character is the first in a native path.  A native path
   conforms to the normal pathname syntax of the server. For example:

        Lookup for Canonical Path:

                LOOKUP FH=0x0 "/a/b/c"

        Lookup for Native Path:

                LOOKUP FH=0x0  0x80 "a:b:c"

6.2 Symbolic Links

   On Unix servers, components within a pathname may be symbolic links.
   The server will evaluate these symbolic links as a part of the normal
   pathname evaluation process.  If the final component is a symbolic
   link, the server will return its filehandle, rather than evaluate it.

   If the attributes returned with a filehandle indicate that it refers
   to a symbolic link, then it is the client's responsibility to deal
   with the link by fetching the contents of the link using the READLINK
   procedure. What follows is determined by the contents of the link.

   Evaluation of symbolic links by the client is defined only if the
   symbolic link is retrieved via the multi-component lookup of a
   canonical path.











Callaghan                    Informational                      [Page 7]

RFC 2054              WebNFS Client Specification           October 1996


6.2.1 Absolute Link

   If the first character of the link text is a slash "/", then the
   following path can be assumed to be absolute.  The entire path must
   be evaluated by the server relative to the public filehandle:

        LOOKUP  FH=0x0  "a/b"  --->
                               <---  FH=0x1 (symbolic link)
        READLINK FH=0x1        --->
                               <---  "/x/y"
        LOOKUP  FH=0x0  "/x/y"
                               <---  FH=0x2

   So in this case the client just passes the link text back to the
   server for evaluation.

6.2.2 Relative Link

   If the first character of the link text is not a slash, then the
   following path can be assumed to be relative to the location of the
   symbolic link.  To evaluate this correctly, the client must
   substitute the link text in place of the final pathname component
   that named the link and issue a another LOOKUP relative to the public
   filehandle.

        LOOKUP  FH=0x0  "a/b"  --->
                               <---  FH=0x1 (symbolic link)
        READLINK FH=0x1        --->
                               <---  "x/y"
        LOOKUP  FH=0x0  "a/x/y"
                               <---  FH=0x2

   By substituting the link text in the link path and having the server
   evaluate the new path, the server effectively gets to evaluate the
   link relative to the link's location.

   The client may also "clean up" the resulting pathname by removing
   redundant components as described in Section 4. of RFC 1808.













Callaghan                    Informational                      [Page 8]

RFC 2054              WebNFS Client Specification           October 1996


6.3 Filesystem Spanning Pathnames

   NFS LOOKUP requests normally do not cross from one filesystem to
   another on the server.  For instance if the server has the following
   export and mounts:

      /export           (exported)

      /export/bigdata   (mountpoint)

   then an NFS LOOKUP for "bigdata" using the filehandle for "/export"
   will return a "no file" error because the LOOKUP request did not
   cross the mountpoint on the server.  There is a practical reason for
   this limitation: if the server permitted the mountpoint crossing to
   occur, then a Unix client might receive ambiguous fileid information
   inconsistent with it's view of a single remote mount for "/export".
   It is expected that the client resolve this by mirroring the
   additional server mount, e.g.

      Client                           Server

      /mnt         <--- mounted on --- /export

      /mnt/bigdata <--- mounted on --- /export/bigdata

   However, this semantic changes if the client issues the filesystem
   spanning LOOKUP relative to the public filehandle. If the following
   filesystems are exported:

      /export           (exported public)

      /export/bigdata   (exported mountpoint)

   then an NFS LOOKUP for "bigdata" relative to the public filehandle
   will cross the mountpoint - just as if the client had issued a MOUNT
   request - but only if the new filesystem is exported, and only if the
   server supports Export Spanning Pathnames described in Section 6.3 of
   RFC 2055 [RFC2055].

7. Contacting the Server

   WebNFS clients should be optimistic in assuming that the server
   supports WebNFS, but should be capable of fallback to conventional
   methods for server access if the server does not support WebNFS.







Callaghan                    Informational                      [Page 9]

RFC 2054              WebNFS Client Specification           October 1996


   The client should start with the assumption that the server supports:

     - NFS version 3.

     - NFS TCP connections.

     - Public Filehandles.

   If these assumptions are not met, the client should fall back
   gracefully with a minimum number of messages. The following steps are
   recommended:

   1. Attempt to create a TCP connection to the server's
      port 2049.

      If the connection fails then assume that a request
      sent over UDP will work.  Use UDP port 2049.

      Do not use the PORTMAP protocol to determine the
      server's port unless the server does not respond to
      port 2049 for both TCP and UDP.

   2. Assume WebNFS and V3 are supported.
      Send an NFS version 3 LOOKUP with the public filehandle
      for the requested pathname.

      If the server returns an RPC PROG_MISMATCH error then
      assume that NFS version 3 is not supported.  Retry
      the LOOKUP with an NFS version 2 public filehandle.

      Note: The first call may not necessarily be a LOOKUP
      if the operation is directed at the public filehandle
      itself, e.g. a READDIR or READDIRPLUS of the directory
      that is associated with the public filehandle.

      If the server returns an NFS3ERR_STALE, NFS3ERR_INVAL, or
      NFS3ERR_BADHANDLE error, then assume that the server does
      not support WebNFS since it does not recognize the public
      filehandle. The client must use the server's portmap
      service to locate and use the MOUNT protocol to obtain an
      initial filehandle for the requested path.

   WebNFS clients can benefit by caching information about the server:
   whether the server supports TCP connections (if TCP is supported then
   the client should cache the TCP connection as well), which protocol
   the server supports and whether the server supports public
   filehandles.  If the server does not support public filehandles, the
   client may choose to cache the port assignment of the MOUNT service



Callaghan                    Informational                     [Page 10]

RFC 2054              WebNFS Client Specification           October 1996


   as well as previously used pathnames and their filehandles.

8. Mount Protocol

   If the server returns an error to the client that indicates no
   support for public filehandles, the client must use the MOUNT
   protocol to convert the given pathname to a filehandle.  Version 1 of
   the MOUNT protocol is described in Appendix A of RFC 1094 and version
   3 in Appendix I of RFC 1813. Version 2 of the MOUNT protocol is
   identical to version 1 except for the addition of a procedure
   MOUNTPROC_PATHCONF which returns POSIX pathconf information from the
   server.

   At this point the client must already have some indication as to
   which version of the NFS protocol is supported on the server.  Since
   the filehandle format differs between NFS versions 2 and 3, the
   client must select the appropriate version of the MOUNT protocol.
   MOUNT versions 1 and 2 return only NFS version 2 filehandles, whereas
   MOUNT version 3 returns NFS version 3 filehandles.

   Unlike the NFS service, the MOUNT service is not registered on a
   well-known port.  The client must use the PORTMAP service to locate
   the server's MOUNT port before it can transmit a MOUNTPROC_MNT
   request to retrieve the filehandle corresponding to the requested
   path.

       Client                                       Server
       ------                                       ------

       -------------- MOUNT port ? -------------->  Portmapper
       <-------------- Port=984 ------------------

       ------- Filehandle for /export/foo ?  ---->  Mountd @ port 984
       <--------- Filehandle=0xf82455ce0..  ------