rfc2055.txt

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


RFC 2055              WebNFS Server Specification           October 1996


6.2 Symbolic Links

   Servers that support symbolic links may encounter pathname components
   that are symbolic links.  The server is expected to evaluate these
   symbolic links as a part of the normal pathname evaluation process.
   This is a different semantic from that of conventional component-at-
   a-time pathname evaluation by NFS clients, where the client is
   expected to do the evaluation.

   However, if the final component is a symbolic link, the server must
   return its filehandle and let the client evaluate it.

6.3 Export Spanning Pathnames

   The server may evaluate a pathname, either through a multi-component
   LOOKUP or as a symbolic link embedded in a pathname, that references
   a file or directory outside of the exported hierarchy.

   Clearly, if the destination of the path is not in an exported
   filesystem, then the server must return an error to the client.

   Many NFS server implementations rely on the MOUNT protocol for
   checking access to exported filesystems and NFS server does no access
   checking.  The NFS server assumes that the filehandle does double
   duty: identifying a file as well as being a security token. Since
   WebNFS clients do not normally use the MOUNT protocol, a server that
   relies on MOUNT checking cannot automatically grant access to another
   exported filesystem at the destination of a spanning path. These
   servers must return an error.

   For example: the server exports two filesystems.  One is associated
   with the public filehandle.

      /export/this   (public filehandle)

      /export/that

   The server receives a LOOKUP request with the public filehandle that
   identifies a file or directory in the other exported filesystem:

      LOOKUP 0x0  "../that/file"
   or
      LOOKUP 0x0  "/export/that/file"

   Even though the pathname destination is in an exported filesystem,
   the server cannot return a filehandle without an assurance that the
   client's use of this filehandle will be authorized.




Callaghan                    Informational                      [Page 6]

RFC 2055              WebNFS Server Specification           October 1996


   Servers that check client access to an export on every NFS request
   have more flexibility.  These servers can return filehandles for
   paths that span exports since the client's use of the filehandle for
   the destination filesystem will be checked by the NFS server.

7. Location of Public Filehandle

   A server administrator can associate the public filehandle with any
   file or directory. For instance, a WebNFS server administrator could
   attach the public filehandle to the root of an anonymous FTP archive,
   so that anonymous FTP pathnames could be used to identify files in
   the FTP hierarchy, e.g.

      # share -o ro,public  /export/ftp

   On servers that support spanning paths, the public filehandle need
   not necessarily be attached to an exported directory, though a
   successful LOOKUP relative to the public filehandle must identify a
   file or directory that is exported.

   For instance, if an NFS server exports a directory "/export/foo" and
   the public filehandle is attached to the server's root directory,
   then a LOOKUP of "export/foo" relative to the public filehandle will
   return a valid file handle but a LOOKUP of "export" will return an
   access error since the server's "/export" directory is not exported.

               /            (public filehandle is here)
              /\
             /  \
            /   export      (not exported)
           /    /\
          /    /  \
         /    /   foo       (exported)


      LOOKUP 0x0  "export"      (returns an error)

      LOOKUP 0x0  "export/foo"  (returns an filehandle)

8. Index Files

   Most HTTP servers support the concept of an index file.  If a browser
   references a directory that contains an index file, then the server
   will return the contents of the index file rather than a directory
   listing.  For instance if a browser requests "a/b/c" then the server
   might return the contents of "a/b/c/index.html".





Callaghan                    Informational                      [Page 7]

RFC 2055              WebNFS Server Specification           October 1996


   A WebNFS server may choose to emulate this feature for the benefit of
   clients using the NFS protocol to browse a Web hierarchy. On
   receiving a multi-component lookup for a canonical path that names a
   directory, the server can check that directory for the presence of an
   index file.  If the file exists then the server may choose to return
   the filehandle of the index file instead of the directory.  Index
   files are commonly called "index.html" though the name is usually
   configurable.

9. Bibliography

   [RFC1831]       Srinivasan, R., "RPC: Remote Procedure Call
                   Protocol Specification Version 2", RFC 1831,
                   August 1995.
                   http://www.internic.net/rfc/rfc1831.txt

   [RFC1832]       Srinivasan, R., "XDR: External Data Representation
                   Standard," RFC 1832, August 1995.
                   http://www.internic.net/rfc/rfc1832.txt

   [RFC1833]       Srinivasan, R., "Binding Protocols for ONC RPC
                   Version 2", RFC 1833, August 1995.
                   http://www.internic.net/rfc/rfc1833.txt

   [RFC1094]       Sun Microsystems, Inc., "Network Filesystem
                   Specification", RFC 1094, March 1989.  NFS
                   version 2 protocol specification.
                   http://www.internic.net/rfc/rfc1094.txt

   [RFC1813]       Sun Microsystems, Inc., "NFS Version 3 Protocol
                   Specification", RFC 1813, June 1995.  NFS version
                   3 protocol specification.
                   http://www.internic.net/rfc/rfc1813.txt

   [RFC2054]       Callaghan, B., "WebNFS Client Specification",
                   RFC 2054, October 1996.
                   http://www.internic.net/rfc/rfc2054.txt

   [Sandberg]      Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh,
                   B.  Lyon, "Design and Implementation of the Sun
                   Network Filesystem," USENIX Conference
                   Proceedings, USENIX Association, Berkeley, CA,
                   Summer 1985.  The basic paper describing the
                   SunOS implementation of the NFS version 2
                   protocol, and discusses the goals, protocol
                   specification and trade-offs.





Callaghan                    Informational                      [Page 8]

RFC 2055              WebNFS Server Specification           October 1996


   [X/OpenNFS]     X/Open Company, Ltd., X/Open CAE Specification:
                   Protocols for X/Open Internetworking: XNFS,
                   X/Open Company, Ltd., Apex Plaza, Forbury Road,
                   Reading Berkshire, RG1 1AX, United Kingdom,
                   1991.  This is an indispensable reference for
                   NFS version 2 protocol and accompanying
                   protocols, including the Lock Manager and the
                   Portmapper.

   [X/OpenPCNFS]   X/Open Company, Ltd., X/Open CAE Specification:
                   Protocols for X/Open Internetworking: (PC)NFS,
                   Developer's Specification, X/Open Company, Ltd.,
                   Apex Plaza, Forbury Road, Reading Berkshire, RG1
                   1AX, United Kingdom, 1991.  This is an
                   indispensable reference for NFS version 2
                   protocol and accompanying protocols, including
                   the Lock Manager and the Portmapper.

10. Security Considerations

   Since the WebNFS server features are based on NFS protocol versions 2
   and 3, the RPC security considerations described in RFC 1094, RFC
   1813, and Appendix A of RFC 1831 apply here also.

   Clients and servers may separately negotiate secure connection
   schemes for authentication, data integrity, and privacy.

   Implementors must note carefully the implications of export spanning
   pathnames as described in section 6.3.

11. Acknowledgements

   This specification was extensively reviewed by the NFS group at
   SunSoft and brainstormed by Michael Eisler.

















Callaghan                    Informational                      [Page 9]

RFC 2055              WebNFS Server Specification           October 1996


12. Author's Address

   Address comments related to this document to:

   [e-mail]


   Brent Callaghan
   Sun Microsystems, Inc.
   2550 Garcia Avenue
   Mailstop Mpk17-201
   Mountain View, CA 94043-1100

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



































Callaghan                    Informational                     [Page 10]