WebNFS Server Specification
RFC 2055

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00

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

                      WebNFS Server Specification

Status of this Memo

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

Abstract

   This document describes the specifications for a server of WebNFS
   clients.  WebNFS extends the semantics of versions 2 and 3 of the NFS
   protocols to allow clients to obtain filehandles more easily, without
   recourse to the portmap or MOUNT protocols.  In removing the need for
   these protocols, WebNFS clients see benefits in faster response to
   requests, easy transit of firewalls and better server scalability
   This description is provided to facilitate compatible implementations
   of WebNFS servers.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
   2.    TCP vs UDP . . . . . . . . . . . . .   . . . . . . . . . . 2
   3.    Well-known Port  . . . . . . . . . . . . . . . . . . . . . 2
   4.    Server Port Monitoring . . . . . . . . . . . . . . . . . . 3
   5.    Public Filehandle  . . . . . . . . . . . . . . . . . . . . 3
   5.1     Version 2 Public Filehandle  . . . . . . . . . . . . . . 3
   5.2     Version 3 Public Filehandle  . . . . . . . . . . . . . . 4
   6.    Multi-component Lookup . . . . . . . . . . . . . . . . . . 4
   6.1     Canonical Path vs. Native Path . . . . . . . . . . . . . 5
   6.2     Symbolic Links . . . . . . . . . . . . . . . . . . . . . 6
   6.3     Export Spanning Pathnames  . . . . . . . . . . . . . . . 6
   7.    Location of Public Filehandle  . . . . . . . . . . . . . . 7
   8.    Index Files  . . . . . . . . . . . . . . . . . . . . . . . 7
   9.    Bibliography . . . . . . . . . . . . . . . . . . . . . . . 8
   10.   Security Considerations  . . . . . . . . . . . . . . . . . 9
   11.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . 9
   12.   Author's Address . . . . . . . . . . . . . . . . . . . . . 10

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

1. Introduction

   The NFS protocol provides access to shared filesystems across
   networks.  It is intended to be machine, operating system, network
   architecture, and transport independent.  The protocol currently
   exists in two versions: version 2 [RFC1094] and version 3 [RFC1813],
   both built on Sun RPC [RFC1831] and its associated eXternal Data
   Representation (XDR) [RFC1832]. This document assumes some
   familiarity with the NFS protocol and underlying RPC protocols.

   WebNFS servers implement semantic extensions to both versions of the
   NFS protocol to support a lightweight binding mechanism for
   conventional or web browser clients that need to communicate with NFS
   servers across the Internet. a WebNFS server supports the public
   filehandle and multi-component lookup features described herein, as
   well as meeting some additional requirements.

   For a description of WebNFS client requirements, read RFC 2054.

2. TCP vs UDP

   The NFS protocol is most well known for its use of UDP which performs
   acceptably on local area networks.  However, on wide area networks
   with error prone, high-latency connections and bandwidth contention,
   TCP is well respected for its congestion control and superior error
   handling.  A growing number of NFS implementations now support the
   NFS protocol over TCP connections.

   A WebNFS client will first attempt to connect to its server with a
   TCP connection.  If the server refuses the connection, the client
   will attempt to use UDP.  All WebNFS servers should support client
   use of TCP and must support UDP.

3. Well-known Port

   While Internet protocols are generally identified by registered port
   number assignments, RPC based protocols register a 32 bit program
   number and a dynamically assigned port with the portmap service which
   is registered on the well-known port 111.  Since the NFS protocol is
   RPC-based, NFS servers register their port assignment with the
   portmap service.

   NFS servers are constrained by a requirement to re-register at the
   same port after a server crash and recovery so that clients can
   recover simply by retransmitting an RPC request until a response is
   received.  This is simpler than the alternative of having the client
   repeatedly check with the portmap service for a new port assignment.
   NFS servers typically achieve this port invariance by registering a

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

   constant port assignment, 2049, for both UDP and TCP.