changeset 497:e60a6ec4aa85

2004-7-12 Brian Masney <[e-mail]> * docs/rfcs/* - added RFCs that are used by this program

--- a/ChangeLog	Sun Jul 11 11:15:36 2004 +0000
+++ b/ChangeLog	Tue Jul 13 01:35:15 2004 +0000
@@ -1,3 +1,6 @@
+2004-7-12 Brian Masney <[e-mail]>
+	* docs/rfcs/* - added RFCs that are used by this program
+
 2004-7-11 Brian Masney <[e-mail]>
 	* src/gtk/gftp-gtk.c src/gtk/gftp-gtk.h src/gtk/gtkui.c 
 	src/gtk/transfer.c - removed use_cache argument to ftp_list_files()
@@ -2534,7 +2537,7 @@
 
 	* cvsclean - added this script
 
-	* *.[ch] - added $Id: ChangeLog,v 1.275 2004/07/11 11:15:36 masneyb Exp $ tags
+	* *.[ch] - added $Id: ChangeLog,v 1.276 2004/07/13 01:35:15 masneyb Exp $ tags
 
 	* debian/* - updated files from Debian maintainer
 

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/rfcs/draft-ietf-secsh-filexfer-04.txt	Tue Jul 13 01:35:15 2004 +0000
@@ -0,0 +1,2130 @@
+
+
+
+Secure Shell Working Group                                  J. Galbraith
+Internet-Draft                                          VanDyke Software
+Expires: June 18, 2003                                         T. Ylonen
+                                                             S. Lehtinen
+                                        SSH Communications Security Corp
+                                                       December 18, 2002
+
+
+                       SSH File Transfer Protocol
+                    draft-ietf-secsh-filexfer-04.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at http://
+   www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on June 18, 2003.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   The SSH File Transfer Protocol provides secure file transfer
+   functionality over any reliable data stream.  It is the standard file
+   transfer protocol for use with the SSH2 protocol.  This document
+   describes the file transfer protocol and its interface to the SSH2
+   protocol suite.
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                  [Page 1]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+Table of Contents
+
+   1.     Introduction . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.     Use with the SSH Connection Protocol . . . . . . . . . . .   4
+   3.     General Packet Format  . . . . . . . . . . . . . . . . . .   5
+   3.1    The use of stderr in the server  . . . . . . . . . . . . .   6
+   4.     Protocol Initialization  . . . . . . . . . . . . . . . . .   8
+   4.1    Client Initialization  . . . . . . . . . . . . . . . . . .   8
+   4.2    Server Initialization  . . . . . . . . . . . . . . . . . .   8
+   4.3    Determining Server Newline Convention  . . . . . . . . . .   9
+   5.     File Attributes  . . . . . . . . . . . . . . . . . . . . .  10
+   5.1    Flags  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
+   5.2    Type . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
+   5.3    Size . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
+   5.4    Owner and Group  . . . . . . . . . . . . . . . . . . . . .  11
+   5.5    Permissions  . . . . . . . . . . . . . . . . . . . . . . .  12
+   5.6    Times  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
+   5.7    ACL  . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
+   5.8    Extended attributes  . . . . . . . . . . . . . . . . . . .  14
+   6.     Requests From the Client to the Server . . . . . . . . . .  15
+   6.1    Request Synchronization and Reordering . . . . . . . . . .  15
+   6.2    File Names . . . . . . . . . . . . . . . . . . . . . . . .  16
+   6.3    Opening, Creating, and Closing Files . . . . . . . . . . .  16
+   6.4    Reading and Writing  . . . . . . . . . . . . . . . . . . .  19
+   6.5    Removing and Renaming Files  . . . . . . . . . . . . . . .  20
+   6.6    Creating and Deleting Directories  . . . . . . . . . . . .  21
+   6.7    Scanning Directories . . . . . . . . . . . . . . . . . . .  21
+   6.8    Retrieving File Attributes . . . . . . . . . . . . . . . .  22
+   6.9    Setting File Attributes  . . . . . . . . . . . . . . . . .  23
+   6.10   Dealing with Symbolic links  . . . . . . . . . . . . . . .  24
+   6.11   Canonicalizing the Server-Side Path Name . . . . . . . . .  25
+   6.11.1 Best practice for dealing with paths . . . . . . . . . . .  25
+   7.     Responses from the Server to the Client  . . . . . . . . .  26
+   8.     Vendor-Specific Extensions . . . . . . . . . . . . . . . .  30
+   9.     Security Considerations  . . . . . . . . . . . . . . . . .  31
+   10.    Changes from previous protocol versions  . . . . . . . . .  32
+   10.1   Changes between versions 4 and 3 . . . . . . . . . . . . .  32
+   10.2   Changes between versions 3 and 2 . . . . . . . . . . . . .  33
+   10.3   Changes between versions 2 and 1 . . . . . . . . . . . . .  33
+   10.4   Changes between versions 1 and 0 . . . . . . . . . . . . .  33
+   11.    Trademark Issues . . . . . . . . . . . . . . . . . . . . .  34
+          References . . . . . . . . . . . . . . . . . . . . . . . .  35
+          Authors' Addresses . . . . . . . . . . . . . . . . . . . .  35
+          Intellectual Property and Copyright Statements . . . . . .  37
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                  [Page 2]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+1. Introduction
+
+   This protocol provides secure file transfer (and more generally file
+   system access) functionality over a reliable data stream, such as a
+   channel in the SSH2 protocol [5].
+
+   This protocol is designed so that it could be used to implement a
+   secure remote file system service, as well as a secure file transfer
+   service.
+
+   This protocol assumes that it runs over a secure channel, and that
+   the server has already authenticated the user at the client end, and
+   that the identity of the client user is externally available to the
+   server implementation.
+
+   In general, this protocol follows a simple request-response model.
+   Each request and response contains a sequence number and multiple
+   requests may be pending simultaneously.  There are a relatively large
+   number of different request messages, but a small number of possible
+   response messages.  Each request has one or more response messages
+   that may be returned in result (e.g., a read either returns data or
+   reports error status).
+
+   The packet format descriptions in this specification follow the
+   notation presented in the secsh architecture draft. [5]
+
+   Even though this protocol is described in the context of the SSH2
+   protocol, this protocol is general and independent of the rest of the
+   SSH2 protocol suite.  It could be used in a number of different
+   applications, such as secure file transfer over TLS RFC 2246 [1] and
+   transfer of management information in VPN applications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                  [Page 3]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+2. Use with the SSH Connection Protocol
+
+   When used with the SSH2 Protocol suite, this protocol is intended to
+   be used from the SSH Connection Protocol [7] as a subsystem, as
+   described in section ``Starting a Shell or a Command''.  The
+   subsystem name used with this protocol is "sftp".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                  [Page 4]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+3. General Packet Format
+
+   All packets transmitted over the secure connection are of the
+   following format:
+
+   	uint32             length
+   	byte               type
+   	byte[length - 1]   data payload
+
+   That is, they are just data preceded by 32-bit length and 8-bit type
+   fields.  The `length' is the length of the data area, and does not
+   include the `length' field itself.  The format and interpretation of
+   the data area depends on the packet type.
+
+   All packet descriptions below only specify the packet type and the
+   data that goes into the data field.  Thus, they should be prefixed by
+   the `length' and `type' fields.
+
+   The maximum size of a packet is in practice determined by the client
+   (the maximum size of read or write requests that it sends, plus a few
+   bytes of packet overhead).  All servers SHOULD support packets of at
+   least 34000 bytes (where the packet size refers to the full length,
+   including the header above).  This should allow for reads and writes
+   of at most 32768 bytes.
+
+   There is no limit on the number of outstanding (non-acknowledged)
+   requests that the client may send to the server.  In practice this is
+   limited by the buffering available on the data stream and the queuing
+   performed by the server.  If the server's queues are full, it should
+   not read any more data from the stream, and flow control will prevent
+   the client from sending more requests.  Note, however, that while
+   there is no restriction on the protocol level, the client's API may
+   provide a limit in order to prevent infinite queuing of outgoing
+   requests at the client.
+
+   The following values are defined for packet types.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                  [Page 5]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   	#define SSH_FXP_INIT                1
+   	#define SSH_FXP_VERSION             2
+   	#define SSH_FXP_OPEN                3
+   	#define SSH_FXP_CLOSE               4
+   	#define SSH_FXP_READ                5
+   	#define SSH_FXP_WRITE               6
+   	#define SSH_FXP_LSTAT               7
+   	#define SSH_FXP_FSTAT               8
+   	#define SSH_FXP_SETSTAT             9
+   	#define SSH_FXP_FSETSTAT           10
+   	#define SSH_FXP_OPENDIR            11
+   	#define SSH_FXP_READDIR            12
+   	#define SSH_FXP_REMOVE             13
+   	#define SSH_FXP_MKDIR              14
+   	#define SSH_FXP_RMDIR              15
+   	#define SSH_FXP_REALPATH           16
+   	#define SSH_FXP_STAT               17
+   	#define SSH_FXP_RENAME             18
+   	#define SSH_FXP_READLINK           19
+   	#define SSH_FXP_SYMLINK            20
+
+   	#define SSH_FXP_STATUS            101
+   	#define SSH_FXP_HANDLE            102
+   	#define SSH_FXP_DATA              103
+   	#define SSH_FXP_NAME              104
+   	#define SSH_FXP_ATTRS             105
+
+   	#define SSH_FXP_EXTENDED          200
+   	#define SSH_FXP_EXTENDED_REPLY    201
+
+   	RESERVED_FOR_EXTENSIONS            210-255
+
+   Additional packet types should only be defined if the protocol
+   version number (see Section ``Protocol Initialization'') is
+   incremented, and their use MUST be negotiated using the version
+   number.  However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY
+   packets can be used to implement vendor-specific extensions.  See
+   Section ``Vendor-Specific-Extensions'' for more details.
+
+3.1 The use of stderr in the server
+
+   Packets are sent and received on stdout and stdin.  Data sent on
+   stderr by the server SHOULD be considered debug or supplemental error
+   information, and MAY be displayed to the user.
+
+   For example, during initialization, there is no client request
+   active, so errors or warning information cannot be sent to the client
+   as part of the SFTP protocol at this early stage.  However, the
+
+
+
+Galbraith, et al.        Expires June 18, 2003                  [Page 6]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   errors or warnings MAY be sent as stderr text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                  [Page 7]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+4. Protocol Initialization
+
+   When the file transfer protocol starts, the client first sends a
+   SSH_FXP_INIT (including its version number) packet to the server.
+   The server responds with a SSH_FXP_VERSION packet, supplying the
+   lowest of its own and the client's version number.  Both parties
+   should from then on adhere to particular version of the protocol.
+
+   The version number of the protocol specified in this document is 4.
+   The version number should be incremented for each incompatible
+   revision of this protocol.
+
+4.1 Client Initialization
+
+   The SSH_FXP_INIT packet (from client to server) has the following
+   data:
+
+   		uint32 version
+
+   Version 3 of this protocol allowed clients to include extensions in
+   the SSH_FXP_INIT packet; however, this can cause interoperability
+   problems with version 1 and version 2 servers because the client must
+   send this packet before knowing the servers version.
+
+   In this version of the protocol, clients MUST use the
+   SSH_FXP_EXTENDED packet to send extensions to the server after
+   version exchange has completed.  Clients MUST NOT include extensions
+   in the version packet.  This will prevent interoperability problems
+   with older servers
+
+4.2 Server Initialization
+
+   The SSH_FXP_VERSION packet (from server to client) has the following
+   data:
+
+   		uint32 version
+   		<extension data>
+
+   'version' is the lower of the protocol version supported by the
+   server and the version number received from the client.
+
+   The extension data may be empty, or may be a sequence of
+
+   		string extension_name
+   		string extension_data
+
+   pairs (both strings MUST always be present if one is, but the
+   `extension_data' string may be of zero length).  If present, these
+
+
+
+Galbraith, et al.        Expires June 18, 2003                  [Page 8]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   strings indicate extensions to the baseline protocol.  The
+   `extension_name' field(s) identify the name of the extension.  The
+   name should be of the form "name@domain", where the domain is the DNS
+   domain name of the organization defining the extension.  Additional
+   names that are not of this format may be defined later by the IETF.
+   Implementations MUST silently ignore any extensions whose name they
+   do not recognize.
+
+4.3 Determining Server Newline Convention
+
+   In order to correctly process text files in a cross platform
+   compatible way, the newline convention must be converted from that of
+   the server to that of the client, or, during an upload, from that of
+   the client to that of the server.
+
+   Versions 3 and prior of this protocol made no provisions for
+   processing text files.  Many clients implemented some sort of
+   conversion algorithm, but without either a 'canonical' on the wire
+   format or knowledge of the servers newline convention, correct
+   conversion was not always possible.
+
+   Starting with Version 4, the SSH_FXF_TEXT file open flag (Section
+   6.3) makes it possible to request that the server translate a file to
+   a 'canonical' on the wire format.  This format uses \r\n as the line
+   separator.
+
+   Servers for systems using multiple newline characters (for example,
+   Mac OS X or VMS) or systems using counted records, MUST translate to
+   the canonical form.
+
+   However, to ease the burden of implementation on servers that use a
+   single, simple separator sequence, the following extension allows the
+   canonical format to be changed.
+
+   	string "newline"
+   	string new-canonical-separator (usually "\r" or "\n" or "\r\n")
+
+   All clients MUST support this extension.
+
+   When processing text files, clients SHOULD NOT translate any
+   character or sequence that is not an exact match of the servers
+   newline separator.
+
+   In particular, if the newline sequence being used is the canonical
+   "\r\n" sequence, a lone \r or a lone \n SHOULD be written through
+   without change.
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                  [Page 9]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+5. File Attributes
+
+   A new compound data type is defined for encoding file attributes.
+   The same encoding is used both when returning file attributes from
+   the server and when sending file attributes to the server.  When
+   sending it to the server, the flags field specifies which attributes
+   are included, and the server will use default values for the
+   remaining attributes (or will not modify the values of remaining
+   attributes).  When receiving attributes from the server, the flags
+   specify which attributes are included in the returned data.  The
+   server normally returns all attributes it knows about.
+
+   	uint32   flags
+   	byte     type                 always present
+   	uint64   size                 present only if flag SIZE
+   	string   owner                present only if flag OWNERGROUP
+   	string   group                present only if flag OWNERGROUP
+   	uint32   permissions          present only if flag PERMISSIONS
+   	uint64   atime                present only if flag ACCESSTIME
+   	uint32   atime_nseconds       present only if flag SUBSECOND_TIMES
+   	uint64   createtime           present only if flag CREATETIME
+   	uint32   createtime_nseconds  present only if flag SUBSECOND_TIMES
+   	uint64   mtime                present only if flag MODIFYTIME
+   	uint32   mtime_nseconds       present only if flag SUBSECOND_TIMES
+   	string   acl                  present only if flag ACL
+   	uint32   extended_count       present only if flag EXTENDED
+   	string   extended_type
+   	string   extended_data
+   	...      more extended data (extended_type - extended_data pairs),
+   		   so that number of pairs equals extended_count
+
+
+5.1 Flags
+
+   The `flags' specify which of the fields are present.  Those fields
+   for which the corresponding flag is not set are not present (not
+   included in the packet).  New flags can only be added by incrementing
+   the protocol version number (or by using the extension mechanism
+   described below).
+
+   The flags bits are defined to have the following values:
+
+
+
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 10]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   	#define SSH_FILEXFER_ATTR_SIZE              0x00000001
+   	#define SSH_FILEXFER_ATTR_PERMISSIONS       0x00000040
+   	#define SSH_FILEXFER_ATTR_ACCESSTIME        0x00000008
+   	#define SSH_FILEXFER_ATTR_CREATETIME        0x00000010
+   	#define SSH_FILEXFER_ATTR_MODIFYTIME        0x00000020
+   	#define SSH_FILEXFER_ATTR_ACL               0x00000040
+   	#define SSH_FILEXFER_ATTR_OWNERGROUP        0x00000080
+   	#define SSH_FILEXFER_ATTR_SUBSECOND_TIMES	0x00000100
+   	#define SSH_FILEXFER_ATTR_EXTENDED          0x80000000
+
+   In previous versions of this protocol flags value 0x00000002 was
+   SSH_FILEXFER_ATTR_UIDGID.  This value is now unused, and OWNERGROUP
+   was given a new value in order to ease implementation burden.
+   0x00000002 MUST NOT appear in the mask.  Some future version of this
+   protocol may reuse flag 0x00000002.
+
+5.2 Type
+
+   The type field is always present.  The following types are defined:
+
+   	#define SSH_FILEXFER_TYPE_REGULAR          1
+   	#define SSH_FILEXFER_TYPE_DIRECTORY        2
+   	#define SSH_FILEXFER_TYPE_SYMLINK          3
+   	#define SSH_FILEXFER_TYPE_SPECIAL          4
+   	#define SSH_FILEXFER_TYPE_UNKNOWN          5
+
+   On a POSIX system, these values would be derived from the permission
+   field.
+
+5.3 Size
+
+   The `size' field specifies the size of the file on disk, in bytes.
+   If it is present during file creation, it should be considered a hint
+   as to the files eventual size.
+
+   Files opened with the SSH_FXF_TEXT flag may have a size that is
+   greater or less than the value of the size field.
+
+5.4 Owner and Group
+
+   The `owner' and `group' fields are represented as UTF-8 strings; this
+   is the form used by NFS v4.  See NFS version 4 Protocol.  [3] The
+   following text is selected quotations from section 5.6.
+
+   To avoid a representation that is tied to a particular underlying
+   implementation at the client or server, the use of UTF-8 strings has
+   been chosen.  The string should be of the form user@dns_domain".
+   This will allow for a client and server that do not use the same
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 11]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   local representation the ability to translate to a common syntax that
+   can be interpreted by both.  In the case where there is no
+   translation available to the client or server, the attribute value
+   must be constructed without the "@".  Therefore, the absence of the @
+   from the owner or owner_group attribute signifies that no translation
+   was available and the receiver of the attribute should not place any
+   special meaning with the attribute value.  Even though the attribute
+   value can not be translated, it may still be useful.  In the case of
+   a client, the attribute string may be used for local display of
+   ownership.
+
+5.5 Permissions
+
+   The `permissions' field contains a bit mask of file permissions as
+   defined by POSIX [1].
+
+5.6 Times
+
+   The 'atime', 'createtime', and 'mtime' contain the access, creation,
+   and modification times of the files, respectively.   They are
+   represented as seconds from Jan 1, 1970 in UTC.
+
+   A negative value indicates number of seconds before Jan 1, 1970.  In
+   both cases, if the SSH_FILEXFER_ATTR_SUBSECOND_TIMES flag is set, the
+   nseconds field is to be added to the seconds field for the final time
+   representation.  For example, if the time to be represented is
+   one-half second before 0 hour January 1, 1970, the seconds field
+   would have a value of negative one (-1) and the nseconds fields would
+   have a value of one-half second (500000000).  Values greater than
+   999,999,999 for nseconds are considered invalid.
+
+5.7 ACL
+
+   The 'ACL' field contains an ACL similar to that defined in section
+   5.9 of NFS version 4 Protocol [3].
+
+   	uint32   ace-count
+
+   	repeated ace-count time:
+   	uint32   ace-type
+   	uint32   ace-flag
+   	uint32   ace-mask
+   	string   who [UTF-8]
+
+   ace-type is one of the following four values (taken from NFS Version
+   4 Protocol [3]:
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 12]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   	const ACE4_ACCESS_ALLOWED_ACE_TYPE      = 0x00000000;
+   	const ACE4_ACCESS_DENIED_ACE_TYPE       = 0x00000001;
+   	const ACE4_SYSTEM_AUDIT_ACE_TYPE        = 0x00000002;
+   	const ACE4_SYSTEM_ALARM_ACE_TYPE        = 0x00000003;
+
+   ace-flag is a combination of the following flag values.  See NFS
+   Version 4 Protocol [3] section 5.9.2:
+
+   	const ACE4_FILE_INHERIT_ACE             = 0x00000001;
+   	const ACE4_DIRECTORY_INHERIT_ACE        = 0x00000002;
+   	const ACE4_NO_PROPAGATE_INHERIT_ACE     = 0x00000004;
+   	const ACE4_INHERIT_ONLY_ACE             = 0x00000008;
+   	const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG   = 0x00000010;
+   	const ACE4_FAILED_ACCESS_ACE_FLAG       = 0x00000020;
+   	const ACE4_IDENTIFIER_GROUP             = 0x00000040;
+
+   ace-mask is any combination of the following flags (taken from NFS
+   Version 4 Protocol [3] section 5.9.3:
+
+   	const ACE4_READ_DATA            = 0x00000001;
+   	const ACE4_LIST_DIRECTORY       = 0x00000001;
+   	const ACE4_WRITE_DATA           = 0x00000002;
+   	const ACE4_ADD_FILE             = 0x00000002;
+   	const ACE4_APPEND_DATA          = 0x00000004;
+   	const ACE4_ADD_SUBDIRECTORY     = 0x00000004;
+   	const ACE4_READ_NAMED_ATTRS     = 0x00000008;
+   	const ACE4_WRITE_NAMED_ATTRS    = 0x00000010;
+   	const ACE4_EXECUTE              = 0x00000020;
+   	const ACE4_DELETE_CHILD         = 0x00000040;
+   	const ACE4_READ_ATTRIBUTES      = 0x00000080;
+   	const ACE4_WRITE_ATTRIBUTES     = 0x00000100;
+   	const ACE4_DELETE               = 0x00010000;
+   	const ACE4_READ_ACL             = 0x00020000;
+   	const ACE4_WRITE_ACL            = 0x00040000;
+   	const ACE4_WRITE_OWNER          = 0x00080000;
+   	const ACE4_SYNCHRONIZE          = 0x00100000;
+
+   who is a UTF-8 string of the form described in 'Owner and Group'
+   (Section 5.4)
+
+   Also, as per '5.9.4 ACE who' [3] there are several identifiers that
+   need to be understood universally.  Some of these identifiers cannot
+   be understood when an client access the server, but have meaning when
+   a local process accesses the file.  The ability to display and modify
+   these permissions is permitted over SFTP.
+
+      OWNER         The owner of the file.
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 13]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+      GROUP         The group associated with the file.
+
+      EVERYONE      The world.
+
+      INTERACTIVE   Accessed from an interactive terminal.
+
+      NETWORK       Accessed via the network.
+
+      DIALUP        Accessed as a dialup user to the server.
+
+      BATCH         Accessed from a batch job.
+
+      ANONYMOUS     Accessed without any authentication.
+
+      AUTHENTICATED Any authenticated user (opposite of ANONYMOUS).
+
+      SERVICE       Access from a system service.
+
+   To avoid conflict, these special identifiers are distinguish by an
+   appended "@" and should appear in the form "xxxx@" (note: no domain
+   name after the "@").  For example: ANONYMOUS@.
+
+5.8 Extended attributes
+
+   The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension
+   mechanism for vendor-specific extensions.  If the flag is specified,
+   then the `extended_count' field is present.  It specifies the number
+   of extended_type-extended_data pairs that follow.  Each of these
+   pairs specifies an extended attribute.  For each of the attributes,
+   the extended_type field should be a string of the format
+   "name@domain", where "domain" is a valid, registered domain name and
+   "name" identifies the method.  The IETF may later standardize certain
+   names that deviate from this format (e.g., that do not contain the
+   "@" sign).  The interpretation of `extended_data' depends on the
+   type.  Implementations SHOULD ignore extended data fields that they
+   do not understand.
+
+   Additional fields can be added to the attributes by either defining
+   additional bits to the flags field to indicate their presence, or by
+   defining extended attributes for them.  The extended attributes
+   mechanism is recommended for most purposes; additional flags bits
+   should only be defined by an IETF standards action that also
+   increments the protocol version number.  The use of such new fields
+   MUST be negotiated by the version number in the protocol exchange.
+   It is a protocol error if a packet with unsupported protocol bits is
+   received.
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 14]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+6. Requests From the Client to the Server
+
+   Requests from the client to the server represent the various file
+   system operations.  Each request begins with an `id' field, which is
+   a 32-bit identifier identifying the request (selected by the client).
+   The same identifier will be returned in the response to the request.
+   One possible implementation is a monotonically increasing request
+   sequence number (modulo 2^32).
+
+   Many operations in the protocol operate on open files.  The
+   SSH_FXP_OPEN request can return a file handle (which is an opaque
+   variable-length string) which may be used to access the file later
+   (e.g.  in a read operation).  The client MUST NOT send requests the
+   server with bogus or closed handles.  However, the server MUST
+   perform adequate checks on the handle in order to avoid security
+   risks due to fabricated handles.
+
+   This design allows either stateful and stateless server
+   implementation, as well as an implementation which caches state
+   between requests but may also flush it.  The contents of the file
+   handle string are entirely up to the server and its design.  The
+   client should not modify or attempt to interpret the file handle
+   strings.
+
+   The file handle strings MUST NOT be longer than 256 bytes.
+
+6.1 Request Synchronization and Reordering
+
+   The protocol and implementations MUST process requests relating to
+   the same file in the order in which they are received.  In other
+   words, if an application submits multiple requests to the server, the
+   results in the responses will be the same as if it had sent the
+   requests one at a time and waited for the response in each case.  For
+   example, the server may process non-overlapping read/write requests
+   to the same file in parallel, but overlapping reads and writes cannot
+   be reordered or parallelized.  However, there are no ordering
+   restrictions on the server for processing requests from two different
+   file transfer connections.  The server may interleave and parallelize
+   them at will.
+
+   There are no restrictions on the order in which responses to
+   outstanding requests are delivered to the client, except that the
+   server must ensure fairness in the sense that processing of no
+   request will be indefinitely delayed even if the client is sending
+   other requests so that there are multiple outstanding requests all
+   the time.
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 15]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+6.2 File Names
+
+   This protocol represents file names as strings.  File names are
+   assumed to use the slash ('/') character as a directory separator.
+
+   File names starting with a slash are "absolute", and are relative to
+   the root of the file system.  Names starting with any other character
+   are relative to the user's default directory (home directory).  Note
+   that identifying the user is assumed to take place outside of this
+   protocol.
+
+   Servers SHOULD interpret a path name component ".." as referring to
+   the parent directory, and "." as referring to the current directory.
+   If the server implementation limits access to certain parts of the
+   file system, it must be extra careful in parsing file names when
+   enforcing such restrictions.  There have been numerous reported
+   security bugs where a ".." in a path name has allowed access outside
+   the intended area.
+
+   An empty path name is valid, and it refers to the user's default
+   directory (usually the user's home directory).
+
+   Otherwise, no syntax is defined for file names by this specification.
+   Clients should not make any other assumptions; however, they can
+   splice path name components returned by SSH_FXP_READDIR together
+   using a slash ('/') as the separator, and that will work as expected.
+
+   In order to comply with IETF Policy on Character Sets and Languages
+   [2], all filenames are to be encoded in UTF-8.  The shortest valid
+   UTF-8 encoding of the UNICODE data MUST be used.  The server is
+   responsible for converting the UNICODE data to whatever canonical
+   form it requires.
+
+   For example, if the server requires that precomposed characters
+   always be used, the server MUST NOT assume the filename as sent by
+   the client has this attribute, but must do this normalization itself.
+
+   It is understood that the lack of well-defined semantics for file
+   names may cause interoperability problems between clients and servers
+   using radically different operating systems.  However, this approach
+   is known to work acceptably with most systems, and alternative
+   approaches that e.g.  treat file names as sequences of structured
+   components are quite complicated.
+
+6.3 Opening, Creating, and Closing Files
+
+   Files are opened and created using the SSH_FXP_OPEN message, whose
+   data part is as follows:
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 16]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   	uint32        id
+   	string        filename [UTF-8]
+   	uint32        pflags
+   	ATTRS         attrs
+
+   The `id' field is the request identifier as for all requests.
+
+   The `filename' field specifies the file name.  See Section ``File
+   Names'' for more information.
+
+   The `pflags' field is a bitmask.  The following bits have been
+   defined.
+
+   	#define SSH_FXF_READ            0x00000001
+   	#define SSH_FXF_WRITE           0x00000002
+   	#define SSH_FXF_APPEND          0x00000004
+   	#define SSH_FXF_CREAT           0x00000008
+   	#define SSH_FXF_TRUNC           0x00000010
+   	#define SSH_FXF_EXCL            0x00000020
+   	#define SSH_FXF_TEXT            0x00000040
+
+   These have the following meanings:
+
+   SSH_FXF_READ
+      Open the file for reading.
+
+   SSH_FXF_WRITE
+      Open the file for writing.  If both this and SSH_FXF_READ are
+      specified, the file is opened for both reading and writing.
+
+   SSH_FXF_APPEND
+      Force all writes to append data at the end of the file.  The
+      offset parameter to write will be ignored.
+
+   SSH_FXF_CREAT
+      If this flag is specified, then a new file will be created if one
+      does not already exist (if O_TRUNC is specified, the new file will
+      be truncated to zero length if it previously exists).
+
+   SSH_FXF_TRUNC
+      Forces an existing file with the same name to be truncated to zero
+      length when creating a file by specifying SSH_FXF_CREAT.
+      SSH_FXF_CREAT MUST also be specified if this flag is used.
+
+   SSH_FXF_EXCL
+      Causes the request to fail if the named file already exists.
+      SSH_FXF_CREAT MUST also be specified if this flag is used.
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 17]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   SSH_FXF_TEXT
+      Indicates that the server should treat the file as text and
+      convert it to the canonical newline convention in use.  (See
+      Determining Server Newline Convention. (Section 4.3)
+
+      When a file is opened with the FXF_TEXT flag, the offset field in
+      both the read and write function are ignored.
+
+      Servers MUST correctly process multiple parallel reads and writes
+      correctly in this mode.  Naturally, it is permissible for them to
+      do this by serializing the requests.  It would not be possible for
+      a client to reliably detect a server that does not implement
+      parallel writes in time to prevent damage.
+
+      Clients SHOULD use the SSH_FXF_APPEND flag to append data to a
+      text file rather then using write with a calculated offset.
+
+      To support seeks on text file the following SSH_FXP_EXTENDED
+      packet is defined.
+
+
+
+   	string "text-seek"
+   	string file-handle
+   	uint64 line-number
+
+      line-number is the index of the line number to seek to, where byte
+      0 in the file is line number 0, and the byte directly following
+      the first newline sequence in the file is line number 1 and so on.
+
+      The response to a "text-seek" request is an SSH_FXP_STATUS
+      message.
+
+      An attempt to seek past the end-of-file should result in a
+      SSH_FX_EOF status.
+
+      Servers SHOULD support at least one "text-seek" in order to
+      support resume.  However, a client MUST be prepared to receive
+      SSH_FX_OP_UNSUPPORTED when attempting a "text-seek" operation.
+      The client can then try a fall-back strategy, if it has one.
+
+      Clients MUST be prepared to handle SSH_FX_OP_UNSUPPORTED returned
+      for read or write operations that are not sequential.
+
+   The `attrs' field specifies the initial attributes for the file.
+   Default values will be used for those attributes that are not
+   specified.  See Section ``File Attributes'' for more information.
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 18]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   The response to this message will be either SSH_FXP_HANDLE (if the
+   operation is successful) or SSH_FXP_STATUS (if the operation fails).
+
+   A file is closed by using the SSH_FXP_CLOSE request.  Its data field
+   has the following format:
+
+   	uint32     id
+   	string     handle
+
+   where `id' is the request identifier, and `handle' is a handle
+   previously returned in the response to SSH_FXP_OPEN or
+   SSH_FXP_OPENDIR.  The handle becomes invalid immediately after this
+   request has been sent.
+
+   The response to this request will be a SSH_FXP_STATUS message.  One
+   should note that on some server platforms even a close can fail.
+   This can happen e.g.  if the server operating system caches writes,
+   and an error occurs while flushing cached writes during the close.
+
+6.4 Reading and Writing
+
+   Once a file has been opened, it can be read using the following
+   message:
+
+   	byte       SSH_FXP_READ
+   	uint32     id
+   	string     handle
+   	uint64     offset
+   	uint32     len
+
+   where `id' is the request identifier, `handle' is an open file handle
+   returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative
+   to the beginning of the file from where to start reading, and `len'
+   is the maximum number of bytes to read.
+
+   In response to this request, the server will read as many bytes as it
+   can from the file (up to `len'), and return them in a SSH_FXP_DATA
+   message.  If an error occurs or EOF is encountered before reading any
+   data, the server will respond with SSH_FXP_STATUS.
+
+   For normal disk files, it is normally guaranteed that this will read
+   the specified number of bytes, or up to end of file.  However, if the
+   read length is very long, the server may truncate it if it doesn't
+   support packets of that length.  See General Packet Format (Section
+   3).
+
+   For e.g.  device files this may return fewer bytes than requested.
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 19]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   Writing to a file is achieved using the following message:
+
+   	byte       SSH_FXP_WRITE
+   	uint32     id
+   	string     handle
+   	uint64     offset
+   	string     data
+
+   where `id' is a request identifier, `handle' is a file handle
+   returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the
+   beginning of the file where to start writing, and `data' is the data
+   to be written.
+
+   The write will extend the file if writing beyond the end of the file.
+   It is legal to write way beyond the end of the file; the semantics
+   are to write zeroes from the end of the file to the specified offset
+   and then the data.  On most operating systems, such writes do not
+   allocate disk space but instead leave "holes" in the file.
+
+   The server responds to a write request with a SSH_FXP_STATUS message.
+
+6.5 Removing and Renaming Files
+
+   Files can be removed using the SSH_FXP_REMOVE message.  It has the
+   following format:
+
+   	uint32     id
+   	string     filename [UTF-8]
+
+   where `id' is the request identifier and `filename' is the name of
+   the file to be removed.  See Section ``File Names'' for more
+   information.  This request cannot be used to remove directories.
+
+   The server will respond to this request with a SSH_FXP_STATUS
+   message.
+
+   Files (and directories) can be renamed using the SSH_FXP_RENAME
+   message.  Its data is as follows:
+
+   	uint32     id
+   	string     oldpath [UTF-8]
+   	string     newpath [UTF-8]
+
+   where `id' is the request identifier, `oldpath' is the name of an
+   existing file or directory, and `newpath' is the new name for the
+   file or directory.  It is an error if there already exists a file
+   with the name specified by newpath.  The server may also fail rename
+   requests in other situations, for example if `oldpath' and `newpath'
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 20]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   point to different file systems on the server.
+
+   The server will respond to this request with a SSH_FXP_STATUS
+   message.
+
+6.6 Creating and Deleting Directories
+
+   New directories can be created using the SSH_FXP_MKDIR request.  It
+   has the following format:
+
+   	uint32     id
+   	string     path [UTF-8]
+   	ATTRS      attrs
+
+   where `id' is the request identifier.
+
+   `path' specifies the directory to be created.  See Section ``File
+   Names'' for more information on file names.
+
+   `attrs' specifies the attributes that should be applied to it upon
+   creation.  Attributes are discussed in more detail in Section ``File
+   Attributes''.
+
+   The server will respond to this request with a SSH_FXP_STATUS
+   message.  If a file or directory with the specified path already
+   exists, an error will be returned.
+
+   Directories can be removed using the SSH_FXP_RMDIR request, which has
+   the following format:
+
+   	uint32     id
+   	string     path [UTF-8]
+
+   where `id' is the request identifier, and `path' specifies the
+   directory to be removed.  See Section ``File Names'' for more
+   information on file names.
+
+   The server responds to this request with a SSH_FXP_STATUS message.
+   Errors may be returned from this operation for various reasons,
+   including, but not limited to, the path does not exist, the path does
+   not refer to a directory object, the directory is not empty, or the
+   user has insufficient access or permission to perform the requested
+   operation.
+
+6.7 Scanning Directories
+
+   The files in a directory can be listed using the SSH_FXP_OPENDIR and
+   SSH_FXP_READDIR requests.  Each SSH_FXP_READDIR request returns one
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 21]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   or more file names with full file attributes for each file.  The
+   client should call SSH_FXP_READDIR repeatedly until it has found the
+   file it is looking for or until the server responds with a
+   SSH_FXP_STATUS message indicating an error (normally SSH_FX_EOF if
+   there are no more files in the directory).  The client should then
+   close the handle using the SSH_FXP_CLOSE request.
+
+   The SSH_FXP_OPENDIR opens a directory for reading.  It has the
+   following format:
+
+   	uint32     id
+   	string     path [UTF-8]
+
+   where `id' is the request identifier and `path' is the path name of
+   the directory to be listed (without any trailing slash).  See Section
+   ``File Names'' for more information on file names.  This will return
+   an error if the path does not specify a directory or if the directory
+   is not readable.  The server will respond to this request with either
+   a SSH_FXP_HANDLE or a SSH_FXP_STATUS message.
+
+   Once the directory has been successfully opened, files (and
+   directories) contained in it can be listed using SSH_FXP_READDIR
+   requests.  These are of the format
+
+   	uint32     id
+   	string     handle
+
+   where `id' is the request identifier, and `handle' is a handle
+   returned by SSH_FXP_OPENDIR.  (It is a protocol error to attempt to
+   use an ordinary file handle returned by SSH_FXP_OPEN.)
+
+   The server responds to this request with either a SSH_FXP_NAME or a
+   SSH_FXP_STATUS message.  One or more names may be returned at a time.
+   Full status information is returned for each name in order to speed
+   up typical directory listings.
+
+   If there are no more names available to be read, the server MUST
+   respond with a SSH_FXP_STATUS message with error code of SSH_FX_EOF.
+
+   When the client no longer wishes to read more names from the
+   directory, it SHOULD call SSH_FXP_CLOSE for the handle.  The handle
+   should be closed regardless of whether an error has occurred or not.
+
+6.8 Retrieving File Attributes
+
+   Very often, file attributes are automatically returned by
+   SSH_FXP_READDIR.  However, sometimes there is need to specifically
+   retrieve the attributes for a named file.  This can be done using the
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 22]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests.
+
+   SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT
+   follows symbolic links on the server, whereas SSH_FXP_LSTAT does not
+   follow symbolic links.  Both have the same format:
+
+   	uint32     id
+   	string     path [UTF-8]
+   	uint32     flags
+
+   where `id' is the request identifier, and `path' specifies the file
+   system object for which status is to be returned.  The server
+   responds to this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS.
+
+   The flags field specify the attribute flags in which the client has
+   particular interest.  This is a hint to the server.  For example,
+   because retrieving owner / group and acl information can be an
+   expensive operation under some operating systems, the server may
+   choose not to retrieve this information unless the client expresses a
+   specific interest in it.
+
+   The client has no guarantee the server will provide all the fields
+   that it has expressed an interest in.
+
+   SSH_FXP_FSTAT differs from the others in that it returns status
+   information for an open file (identified by the file handle).  Its
+   format is as follows:
+
+   	uint32     id
+   	string     handle
+   	uint32     flags
+
+   where `id' is the request identifier and `handle' is a file handle
+   returned by SSH_FXP_OPEN.  The server responds to this request with
+   SSH_FXP_ATTRS or SSH_FXP_STATUS.
+
+6.9 Setting File Attributes
+
+   File attributes may be modified using the SSH_FXP_SETSTAT and
+   SSH_FXP_FSETSTAT requests.  These requests are used for operations
+   such as changing the ownership, permissions or access times, as well
+   as for truncating a file.
+
+   The SSH_FXP_SETSTAT request is of the following format:
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 23]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   	uint32     id
+   	string     path [UTF-8]
+   	ATTRS      attrs
+
+   where `id' is the request identifier, `path' specifies the file
+   system object (e.g.  file or directory) whose attributes are to be
+   modified, and `attrs' specifies the modifications to be made to its
+   attributes.  Attributes are discussed in more detail in Section
+   ``File Attributes''.
+
+   An error will be returned if the specified file system object does
+   not exist or the user does not have sufficient rights to modify the
+   specified attributes.  The server responds to this request with a
+   SSH_FXP_STATUS message.
+
+   The SSH_FXP_FSETSTAT request modifies the attributes of a file which
+   is already open.  It has the following format:
+
+   	uint32     id
+   	string     handle
+   	ATTRS      attrs
+
+   where `id' is the request identifier, `handle' (MUST be returned by
+   SSH_FXP_OPEN) identifies the file whose attributes are to be
+   modified, and `attrs' specifies the modifications to be made to its
+   attributes.  Attributes are discussed in more detail in Section
+   ``File Attributes''.  The server will respond to this request with
+   SSH_FXP_STATUS.
+
+6.10 Dealing with Symbolic links
+
+   The SSH_FXP_READLINK request may be used to read the target of a
+   symbolic link.  It would have a data part as follows:
+
+   	uint32     id
+   	string     path [UTF-8]
+
+   where `id' is the request identifier and `path' specifies the path
+   name of the symlink to be read.
+
+   The server will respond with a SSH_FXP_NAME packet containing only
+   one name and a dummy attributes value.  The name in the returned
+   packet contains the target of the link.  If an error occurs, the
+   server may respond with SSH_FXP_STATUS.
+
+   The SSH_FXP_SYMLINK request will create a symbolic link on the
+   server.  It is of the following format
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 24]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   	uint32     id
+   	string     linkpath   [UTF-8]
+   	string     targetpath [UTF-8]
+
+   where `id' is the request identifier, `linkpath' specifies the path
+   name of the symlink to be created and `targetpath' specifies the
+   target of the symlink.  The server shall respond with a
+   SSH_FXP_STATUS indicating either success (SSH_FX_OK) or an error
+   condition.
+
+6.11 Canonicalizing the Server-Side Path Name
+
+   The SSH_FXP_REALPATH request can be used to have the server
+   canonicalize any given path name to an absolute path.  This is useful
+   for converting path names containing ".." components or relative
+   pathnames without a leading slash into absolute paths.  The format of
+   the request is as follows:
+
+   	uint32     id
+   	string     path [UTF-8]
+
+   where `id' is the request identifier and `path' specifies the path
+   name to be canonicalized.  The server will respond with a
+   SSH_FXP_NAME packet containing the name in canonical form and a dummy
+   attributes value.  If an error occurs, the server may also respond
+   with SSH_FXP_STATUS.
+
+6.11.1 Best practice for dealing with paths
+
+   The client SHOULD treat the results of SSH_FXP_REALPATH as a
+   canonical absolute path, even if the path does not appear to be
+   absolute.  A client that use REALPATH(".") and treats the result as
+   absolute, even if there is no leading slash, will continue to
+   function correctly, even when talking to a Windows NT or VMS style
+   system, where absolute paths may not begin with a slash.
+
+   For example, if the client wishes to change directory up, and the
+   server has returned "c:/x/y/z" from REALPATH, the client SHOULD use
+   "c:/x/y/z/..".
+
+   As a second example, if the client wishes to open the file "x.txt" in
+   the current directory, and server has returned "dka100:/x/y/z" as the
+   canonical path of the directory, the client SHOULD open "dka100:/x/y/
+   z/x.txt"
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 25]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+7. Responses from the Server to the Client
+
+   The server responds to the client using one of a few response
+   packets.  All requests can return a SSH_FXP_STATUS response upon
+   failure.  When the operation is successful, any of the responses may
+   be returned (depending on the operation).  If no data needs to be
+   returned to the client, the SSH_FXP_STATUS response with SSH_FX_OK
+   status is appropriate.  Otherwise, the SSH_FXP_HANDLE message is used
+   to return a file handle (for SSH_FXP_OPEN and SSH_FXP_OPENDIR
+   requests), SSH_FXP_DATA is used to return data from SSH_FXP_READ,
+   SSH_FXP_NAME is used to return one or more file names from a
+   SSH_FXP_READDIR or SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is
+   used to return file attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and
+   SSH_FXP_FSTAT requests.
+
+   Exactly one response will be returned for each request.  Each
+   response packet contains a request identifier which can be used to
+   match each response with the corresponding request.  Note that it is
+   legal to have several requests outstanding simultaneously, and the
+   server is allowed to send responses to them in a different order from
+   the order in which the requests were sent (the result of their
+   execution, however, is guaranteed to be as if they had been processed
+   one at a time in the order in which the requests were sent).
+
+   Response packets are of the same general format as request packets.
+   Each response packet begins with the request identifier.
+
+   The format of the data portion of the SSH_FXP_STATUS response is as
+   follows:
+
+   	uint32     id
+   	uint32     error/status code
+   	string     error message (ISO-10646 UTF-8 [RFC-2279])
+   	string     language tag (as defined in [RFC-1766])
+
+   where `id' is the request identifier, and `error/status code'
+   indicates the result of the requested operation.  The value SSH_FX_OK
+   indicates success, and all other values indicate failure.
+
+   Currently, the following values are defined (other values may be
+   defined by future versions of this protocol):
+
+
+
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 26]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   	#define SSH_FX_OK                            0
+   	#define SSH_FX_EOF                           1
+   	#define SSH_FX_NO_SUCH_FILE                  2
+   	#define SSH_FX_PERMISSION_DENIED             3
+   	#define SSH_FX_FAILURE                       4
+   	#define SSH_FX_BAD_MESSAGE                   5
+   	#define SSH_FX_NO_CONNECTION                 6
+   	#define SSH_FX_CONNECTION_LOST               7
+   	#define SSH_FX_OP_UNSUPPORTED                8
+   	#define SSH_FX_INVALID_HANDLE                9
+   	#define SSH_FX_NO_SUCH_PATH                  10
+   	#define SSH_FX_FILE_ALREADY_EXISTS           11
+   	#define SSH_FX_WRITE_PROTECT                 12
+   	#define SSH_FX_NO_MEDIA                      13
+
+   SSH_FX_OK
+      Indicates successful completion of the operation.
+
+   SSH_FX_EOF
+      indicates end-of-file condition; for SSH_FX_READ it means that no
+      more data is available in the file, and for SSH_FX_READDIR it
+      indicates that no more files are contained in the directory.
+
+   SSH_FX_NO_SUCH_FILE
+      is returned when a reference is made to a file which does not
+      exist.
+
+   SSH_FX_PERMISSION_DENIED
+      is returned when the authenticated user does not have sufficient
+      permissions to perform the operation.
+
+   SSH_FX_FAILURE
+      is a generic catch-all error message; it should be returned if an
+      error occurs for which there is no more specific error code
+      defined.
+
+   SSH_FX_BAD_MESSAGE
+      may be returned if a badly formatted packet or protocol
+      incompatibility is detected.
+
+   SSH_FX_NO_CONNECTION
+      is a pseudo-error which indicates that the client has no
+      connection to the server (it can only be generated locally by the
+      client, and MUST NOT be returned by servers).
+
+   SSH_FX_CONNECTION_LOST
+      is a pseudo-error which indicates that the connection to the
+      server has been lost (it can only be generated locally by the
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 27]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+      client, and MUST NOT be returned by servers).
+
+   SSH_FX_OP_UNSUPPORTED
+      indicates that an attempt was made to perform an operation which
+      is not supported for the server (it may be generated locally by
+      the client if e.g.  the version number exchange indicates that a
+      required feature is not supported by the server, or it may be
+      returned by the server if the server does not implement an
+      operation).
+
+   SSH_FX_INVALID_HANDLE
+      The handle value was invalid.
+
+   SSH_FX_NO_SUCH_PATH
+      The file path does not exist or is invalid.
+
+   SSH_FX_FILE_ALREADY_EXISTS
+      The file already exists.
+
+   SSH_FX_WRITE_PROTECT
+      The file is on read only media, or the media is write protected.
+
+   SSH_FX_NO_MEDIA
+      The requested operation can not be completed because there is no
+      media available in the drive.
+
+   The SSH_FXP_HANDLE response has the following format:
+
+   	uint32     id
+   	string     handle
+
+   where `id' is the request identifier, and `handle' is an arbitrary
+   string that identifies an open file or directory on the server.  The
+   handle is opaque to the client; the client MUST NOT attempt to
+   interpret or modify it in any way.  The length of the handle string
+   MUST NOT exceed 256 data bytes.
+
+   The SSH_FXP_DATA response has the following format:
+
+   	uint32     id
+   	string     data
+
+   where `id' is the request identifier, and `data' is an arbitrary byte
+   string containing the requested data.  The data string may be at most
+   the number of bytes requested in a SSH_FXP_READ request, but may also
+   be shorter if end of file is reached or if the read is from something
+   other than a regular file.
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 28]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   The SSH_FXP_NAME response has the following format:
+
+   	uint32     id
+   	uint32     count
+   	repeats count times:
+   		string     filename [UTF-8]
+   		ATTRS      attrs
+
+   where `id' is the request identifier, `count' is the number of names
+   returned in this response, and the remaining fields repeat `count'
+   times (so that all three fields are first included for the first
+   file, then for the second file, etc).  In the repeated part,
+   `filename' is a file name being returned (for SSH_FXP_READDIR, it
+   will be a relative name within the directory, without any path
+   components; for SSH_FXP_REALPATH it will be an absolute path name),
+   and `attrs' is the attributes of the file as described in Section
+   ``File Attributes''.
+
+   The SSH_FXP_ATTRS response has the following format:
+
+   	uint32     id
+   	ATTRS      attrs
+
+   where `id' is the request identifier, and `attrs' is the returned
+   file attributes as described in Section ``File Attributes''.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 29]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+8. Vendor-Specific Extensions
+
+   The SSH_FXP_EXTENDED request provides a generic extension mechanism
+   for adding vendor-specific commands.  The request has the following
+   format:
+
+   	uint32     id
+   	string     extended-request
+   	... any request-specific data ...
+
+   where `id' is the request identifier, and `extended-request' is a
+   string of the format "name@domain", where domain is an internet
+   domain name of the vendor defining the request.  The rest of the
+   request is completely vendor-specific, and servers should only
+   attempt to interpret it if they recognize the `extended-request'
+   name.
+
+   The server may respond to such requests using any of the response
+   packets defined in Section ``Responses from the Server to the
+   Client''.  Additionally, the server may also respond with a
+   SSH_FXP_EXTENDED_REPLY packet, as defined below.  If the server does
+   not recognize the `extended-request' name, then the server MUST
+   respond with SSH_FXP_STATUS with error/status set to
+   SSH_FX_OP_UNSUPPORTED.
+
+   The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary
+   extension-specific data from the server to the client.  It is of the
+   following format:
+
+   	uint32     id
+   	... any request-specific data ...
+
+   There is a range of packet types reserved for use by extensions.  In
+   order to avoid collision, extensions that turn on the use of
+   additional packet types should determine those numbers dynamically.
+
+   The suggested way of doing this is have an extension request from the
+   client to the server that enables the extension; the extension
+   response from the server to the client would specify the actual type
+   values to use, in additional to any other data.
+
+   Extension authors should be mindful of the limited range of packet
+   types available (there are only 45 values available) and avoid
+   requiring a new packet type where possible.
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 30]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+9. Security Considerations
+
+   This protocol assumes that it is run over a secure channel and that
+   the endpoints of the channel have been authenticated.  Thus, this
+   protocol assumes that it is externally protected from network-level
+   attacks.
+
+   This protocol provides file system access to arbitrary files on the
+   server (only constrained by the server implementation).  It is the
+   responsibility of the server implementation to enforce any access
+   controls that may be required to limit the access allowed for any
+   particular user (the user being authenticated externally to this
+   protocol, typically using the SSH User Authentication Protocol [8].
+
+   Care must be taken in the server implementation to check the validity
+   of received file handle strings.  The server should not rely on them
+   directly; it MUST check the validity of each handle before relying on
+   it.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 31]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+10. Changes from previous protocol versions
+
+   The SSH File Transfer Protocol has changed over time, before it's
+   standardization.  The following is a description of the incompatible
+   changes between different versions.
+
+10.1 Changes between versions 4 and 3
+
+   Many of the changes between version 4 and version 3 are to the
+   attribute structure to make it more flexible for non-unix platforms.
+
+   o  Clarify the use of stderr by the server.
+
+   o  Clarify handling of very large read requests by the server.
+
+   o  Make all filenames UTF-8.
+
+   o  Added 'newline' extension.
+
+   o  Made time fields 64 bit, and optionally have nanosecond resultion.
+
+   o  Made file attribute owner and group strings so they can actually
+      be used on disparate systems.
+
+   o  Added createtime field, and added separate flags for atime,
+      createtime, and mtime so they can be set separately.
+
+   o  Split the file type out of the permissions field and into it's own
+      field (which is always present.)
+
+   o  Added acl attribute.
+
+   o  Added SSH_FXF_TEXT file open flag.
+
+   o  Added flags field to the get stat commands so that the client can
+      specifically request information the server might not normally
+      included for performance reasons.
+
+   o  Removed the long filename from the names structure-- it can now be
+      built from information available in the attrs structure.
+
+   o  Added reserved range of packet numbers for extensions.
+
+   o  Added several additional error codes.
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 32]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+10.2 Changes between versions 3 and 2
+
+   o  The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added.
+
+   o  The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were
+      added.
+
+   o  The SSH_FXP_STATUS message was changed to include fields `error
+      message' and `language tag'.
+
+
+10.3 Changes between versions 2 and 1
+
+   o  The SSH_FXP_RENAME message was added.
+
+
+10.4 Changes between versions 1 and 0
+
+   o  Implementation changes, no actual protocol changes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 33]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+11. Trademark Issues
+
+   "ssh" is a registered trademark of SSH Communications Security Corp
+   in the United States and/or other countries.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 34]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+References
+
+   [1]  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
+        P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
+        1999.
+
+   [2]  Alvestrand, H., "IETF Policy on Character Sets and Languages",
+        BCP 18, RFC 2277, January 1998.
+
+   [3]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
+        C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC
+        3010, December 2000.
+
+   [4]  Institute of Electrical and Electronics Engineers, "Information
+        Technology - Portable Operating System Interface (POSIX) - Part
+        1: System Application Program Interface (API) [C Language]",
+        IEEE Standard 1003.2, 1996.
+
+   [5]  Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
+        Lehtinen, "SSH Protocol Architecture",
+        draft-ietf-secsh-architecture-13 (work in progress), September
+        2002.
+
+   [6]  Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
+        Lehtinen, "SSH Protocol Transport Protocol",
+        draft-ietf-secsh-transport-15 (work in progress), September
+        2002.
+
+   [7]  Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
+        Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-16
+        (work in progress), September 2002.
+
+   [8]  Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
+        Lehtinen, "SSH Authentication Protocol",
+        draft-ietf-secsh-userauth-16 (work in progress), September 2002.
+
+
+Authors' Addresses
+
+   Joseph Galbraith
+   VanDyke Software
+   4848 Tramway Ridge Blvd
+   Suite 101
+   Albuquerque, NM  87111
+   US
+
+   Phone: [phone]
+   EMail: [e-mail]
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 35]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   Tatu Ylonen
+   SSH Communications Security Corp
+   Fredrikinkatu 42
+   HELSINKI  FIN-00100
+   Finland
+
+   EMail: [e-mail]
+
+
+   Sami Lehtinen
+   SSH Communications Security Corp
+   Fredrikinkatu 42
+   HELSINKI  FIN-00100
+   Finland
+
+   EMail: [e-mail]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 36]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 37]
+
+Internet-Draft         SSH File Transfer Protocol          December 2002
+
+
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galbraith, et al.        Expires June 18, 2003                 [Page 38]
+
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/rfcs/draft-murray-auth-ftp-ssl-09.txt	Tue Jul 13 01:35:15 2004 +0000
@@ -0,0 +1,1679 @@
+
+
+
+
+
+
+                                                    Paul Ford-Hutchinson
+<draft-murray-auth-ftp-ssl-09.txt>                            IBM UK Ltd
+                                                        Martin Carpenter
+                                                            Verisign Inc
+                                                              Tim Hudson
+INTERNET-DRAFT (draft)                                 RSA Australia Ltd
+                                                             Eric Murray
+                                                        Wave Systems Inc
+                                                          Volker Wiegand
+                                                              SuSE Linux
+
+                                                         2nd April, 2002
+This document expires on 2nd October, 2002
+
+
+                         Securing FTP with TLS
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand    FORMFEED[Page 1]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+Index
+      1. .......... Abstract
+      2. .......... Introduction
+      3. .......... Audience
+      4. .......... Session negotiation on the control port
+      5. .......... Response to FEAT command
+      6. .......... Data Connection Behaviour
+      7. .......... Mechanisms for the AUTH Command
+      8. .......... Data Connection Security
+      9. .......... A discussion of negotiation behaviour
+      10. ......... Who negotiates what, where and how
+      11. ......... Timing Diagrams
+      12. ......... Discussion of the REIN command
+      13. ......... Discussion of the STAT and ABOR commands
+      14. ......... Security Considerations
+      15. ......... IANA Considerations
+      16. ......... Other Parameters
+      17. ......... Network Management
+      18. ......... Internationalization
+      19. ......... Scalability & Limits
+      20. ......... Applicability
+      21. ......... Acknowledgements
+      22. ......... References
+      23. ......... Authors' Contact Addresses
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand    FORMFEED[Page 2]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+1. Abstract
+
+   This document describes a mechanism that can be used by FTP clients
+   and servers to implement security and authentication using the TLS
+   protocol defined by [RFC-2246] and the extensions to the FTP protocol
+   defined by [RFC-2228].  It describes the subset of the extensions
+   that are required and the parameters to be used; discusses some of
+   the policy issues that clients and servers will need to take;
+   considers some of the implications of those policies and discusses
+   some expected behaviours of implementations to allow interoperation.
+   This document is intended to provide TLS support for FTP in a similar
+   way to that provided for SMTP in [RFC-2487] and HTTP in [RFC-2817].
+
+   TLS is not the only mechanism for securing file transfer, however it
+   does offer some of the following positive attributes:-
+
+      - Flexible security levels.  TLS can support confidentiality,
+      integrity, authentication or some combination of all of these.
+      This allows clients and servers to dynamically, during a session,
+      decide on the level of security required for a particular data
+      transfer,
+
+      - It is possible to use TLS identities to authenticate client
+      users and not just client hosts.
+
+      - Formalised public key management.  By use of well established
+      client identity mechnisms (supported by TLS) during the
+      authentication phase, certificate management may be built into a
+      central function.  Whilst this may not be desirable for all uses
+      of secured file transfer, it offers advantages in certain
+      structured environments.
+
+      - Co-existence and interoperation with authentication mechanisms
+      that are already in place for the HTTPS protocol.  This allows web
+      browsers to incorporate secure file transfer using the same
+      infrastructure that has been set up to allow secure web browsing.
+
+   The TLS protocol is a development of the Netscape Communication
+   Corporation's SSL protocol and this document can be used to allow the
+   FTP protocol to be used with either SSL or TLS.  The actual protocol
+   used will be decided by the negotiation of the protected session by
+   the TLS/SSL layer.  This document will only refer to the TLS
+   protocol, however, it is understood that the Client and Server MAY
+   actually be using SSL if they are so configured.
+
+   Note that this specification is in accordance with the FTP RFC
+   [RFC-959] and relies on the TLS protocol [RFC-2246] and the FTP
+   security extensions [RFC-2228].
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand    FORMFEED[Page 3]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+2.  Introduction
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
+    "SHALL NOT",  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and
+   "OPTIONAL" that appear in this document are to be interpreted as
+   described in [RFC-2119].
+
+   This document is an attempt to describe how three other documents
+   should combined to provide a useful, interoperable, secure file
+   transfer protocol.  Those documents are:-
+
+
+      RFC 959 [RFC-959]
+
+         The description of the Internet File Transfer Protocol
+
+      RFC 2246 [RFC-2246]
+
+         The description of the Transport Layer Security protocol
+         (developed from the Netscape Secure Sockets Layer (SSL)
+         protocol version 3.0).
+
+      RFC 2228 [RFC-2228]
+
+         Extensions to the FTP protocol to allow negotiation of security
+         mechanisms to allow authentication, confidentiality and message
+         integrity.
+
+   The File Transfer Protocol (FTP) currently defined in [RFC-959] and
+   in place on the Internet is an excellent mechanism for exchanging
+   files.  The security extensions to FTP in [RFC-2228] offer a
+   comprehensive set of commands and responses that can be used to add
+   authentication, integrity and confidentiality to the FTP protocol.
+   The TLS protocol is a popular (due to its wholesale adoption in the
+   HTTP environment) mechanism for generally securing a socket
+   connection.
+   There are many ways in which these three protocols can be combined
+   which would ensure that interoperation is impossible.  This document
+   describes one method by which FTP can operate securely in such a way
+   as to provide both flexibility and interoperation.  This necessitates
+   a brief description of the actual negotiation mechanism ; a much more
+   detailed description of the policies and practices that would be
+   required and a discussion of the expected behaviours of clients and
+   servers to allow either party to impose their security requirements
+   on the FTP session.
+
+
+3.  Audience
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand    FORMFEED[Page 4]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+   This document is aimed at developers who wish to implement TLS as a
+   security mechanism to secure FTP clients and/or servers.
+
+
+4.  Session negotiation on the control port
+
+   The server listens on the normal FTP control port {FTP-PORT} and the
+   session initiation is not secured at all.  Once the client wishes to
+   secure the session, the AUTH command is sent and the server MAY then
+   allow TLS negotiation to take place.
+
+  4.1  Client wants a secured session
+
+     If a client wishes to attempt to secure a session then it SHOULD,
+     in accordance with [RFC-2228] send the AUTH command with the
+     parameter requesting TLS {TLS-PARM}.
+
+
+     The client then needs to behave according to its policies depending
+     on the response received from the server and also the result of the
+     TLS negotiation.  i.e. A client which receives an AUTH rejection
+     MAY choose to continue with the session unprotected if it so
+     desires.
+
+  4.2  Server wants a secured session
+
+     The FTP protocol does not allow a server to directly dictate client
+     behaviour, however the same effect can be achieved by refusing to
+     accept certain FTP commands until the session is secured to an
+     acceptable level to the server.
+
+   The server response to an 'AUTH TLS' command which it will honour, is
+   '234'.
+
+      Note. The '334' response as defined in [RFC-2228] implies that an
+      ADAT exchange will folow.  This document does not use the ADAT
+      command and so the '334' reply is incorrect.
+
+   Note. The FTP protocol insists that a USER command be used to
+   identify the entity attempting to use the ftp server.  Although the
+   TLS negotiation may be providing authentication information the USER
+   command must still be isssued by the client.  However, it will be a
+   server implementation issue to decide which credentials to accept and
+   what consistency checks to make between any client cert used and the
+   parameter on the USER command.
+
+5.  Response to the FEAT command
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand    FORMFEED[Page 5]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+   The FEAT command (introduced in [RFC-2389]) allows servers with
+   additional features to advertise these to a client by responding to
+   the FEAT command.  If a server supports the FEAT command then it MUST
+   advertise supported AUTH, PBSZ and PROT commands in the reply as
+   described in section 3.2 of [RFC-2389].  Additionally, the AUTH
+   command should have a reply that identifies 'TLS' as one of the
+   possible parameters to AUTH.  It is not necessary to identify the
+   'TLS-C' synonym separately.
+
+   Example reply (in same style is [RFC-2389])
+      C> FEAT
+      S> 211-Extensions supported
+      S>  AUTH TLS
+      S>  PBSZ
+      S>  PROT
+      S> 211 END
+
+
+6. Data Connection Behaviour
+
+   The Data Connection in the FTP model can be used in one of three
+   ways.  (Note: these descriptions are not necessarily placed in exact
+   chronological order, but do describe the steps required. - See
+   diagrams later for clarification)
+
+         i) Classic FTP client/server data exchange
+
+         - The client obtains a port; sends the port number to the
+         server; the server connects to the client.  The client issues a
+         send or receive request to the server on the control connection
+         and the data transfer commences on the data connection.
+
+         ii) Firewall-Friendly client/server data exchange (as discussed
+         in [RFC-1579]) using the PASV command to reverse the direction
+         of the data connection.
+
+         - The client requests that the server open a port; the server
+         obtains a port and returns the address and port number to the
+         client; the client connects to the server on this port.  The
+         client issues a send or receive request on the control
+         connection and the data transfer commences on the data
+         connection.
+
+         iii) Client initiated server/server data exchange (proxy or
+         PASV connections)
+
+         - The client requests that server A opens a port; server A
+         obtains a port and returns it to the client; the client sends
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand    FORMFEED[Page 6]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+         this port number to server B.  Server B connects to server A.
+         The client sends a send or receive request to server A and the
+         complement to server B and the data transfer commences.  In
+         this model server A is the proxy or PASV host and is a client
+         for the Data Connection to server B.
+
+   For i) and ii) the FTP client MUST be the TLS client and the FTP
+   server MUST be the TLS server.
+
+   That is to say, it does not matter which side initiates the
+   connection with a connect() call or which side reacts to the
+   connection via the accept() call; the FTP client as defined in
+   [RFC-959] is always the TLS client as defined in [RFC-2246].
+
+   In scenario iii) there is a problem in that neither server A nor
+   server B is the TLS client given the fact that an FTP server must act
+   as a TLS server for Firewall-Friendly FTP [RFC-1579].  Thus this is
+   explicitly excluded in the security extensions document [RFC-2228],
+   and in this document.
+
+
+
+7. Mechanisms for the AUTH Command
+
+   The AUTH command takes a single parameter to define the security
+   mechanism to be negotiated.  As the SSL/TLS protocols self-negotiate
+   their levels there is no need to distinguish SSL vs TLS in the
+   application layer.  The proposed mechanism name for negotiating TLS
+   will be the character string identified in {TLS-PARM}.  This will
+   allow the client and server to negotiate TLS on the control
+   connection without altering the protection of the data channel.  To
+   protect the data channel as well, the PBSZ:PROT command sequence MUST
+   be used.
+
+   Note: The data connection state MAY be modified by the client issuing
+   the PROT command with the new desired level of data channel
+   protection and the server replying in the affirmative.  This data
+   channel protection negotiation can happen at any point in the session
+   (even straight after a PORT or PASV command) and as often as is
+   required.
+
+      See also Section 15, "IANA Considerations".
+
+
+8. Data Connection Security
+
+   The Data Connection security level is determined by the PROT command
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand    FORMFEED[Page 7]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+      The PROT command, as specified in [RFC-2228] allows client/server
+      negotiation of the security level of the data connection.  Once a
+      PROT command has been issued by the client and accepted by the
+      server returning the '200' reply, the security of subsequent data
+      connections MUST be at that level until another PROT command is
+      issued and accepted; the session ends; a REIN command is issued;
+      or the security of the session (via an AUTH command) is re-
+      negotiated.
+
+   Data Connection Security Negotiation (the PROT command)
+
+      Note: In line with [RFC-2228], there is no facility for securing
+      the Data connection with an insecure Control connection.
+      Specifically, the PROT command MUST be preceded by a PBSZ command
+      and a PBSZ command MUST be preceded by a successful security data
+      exchange (the TLS negotiation in this case)
+
+      The command defined in [RFC-2228] to negotiate data connection
+      security is the PROT command.  As defined there are four values
+      that the PROT command parameter can take.
+
+          'C' - Clear - neither Integrity nor Privacy
+
+          'S' - Safe - Integrity without Privacy
+
+          'E' - Confidential - Privacy without Integrity
+
+          'P' - Private - Integrity and Privacy
+
+      As TLS negotiation encompasses (and exceeds) the Safe /
+      Confidential / Private distinction, only Private (use TLS) and
+      Clear (don't use TLS) are used.
+
+      For TLS, the data connection can have one of two security levels.
+
+         1)Clear (requested by 'PROT C')
+
+         2)Private (requested by 'PROT P')
+
+      With 'Clear' protection level, the data connection is made without
+      TLS at all.  Thus the connection is unauthenticated and has no
+      confidentiality or integrity.  This might be the desired behaviour
+      for servers sending file lists, pre-encrypted data or non-
+      sensitive data (e.g. for anonymous FTP servers).
+
+      If the data connection security level is 'Private' then a TLS
+      negotiation must take place on the data connection, to the
+      satisfaction of the Client and Server prior to any data being
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand    FORMFEED[Page 8]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+      transmitted over the connection.  The TLS layers of the Client and
+      Server will be responsible for negotiating the exact TLS Cipher
+      Suites that will be used (and thus the eventual security of the
+      connection).
+
+
+      In addition, the PBSZ (protection buffer size) command, as
+      detailed in [RFC-2228], is compulsory prior to any PROT command.
+      This document also defines a data channel encapsulation mechanism
+      for protected data buffers.  For FTP-TLS, which appears to the FTP
+      application as a streaming protection mechanism, this is not
+      required.  Thus the PBSZ command must still be issued, but must
+      have a parameter of '0' to indicate that no buffering is taking
+      place and the data connection should not be encapsulated.
+       Note that PBSZ 0 is not in the grammar of [RFC-2228], section
+      8.1, where it is stated:
+         PBSZ <sp> <decimal-integer> <CRLF> <decimal-integer> ::= any
+         decimal integer from 1 to (2^32)-1
+      However it should be noted that using a value of '0' to mean a
+      streaming protocol is a reasonable use of '0' for that parameter
+      and is not ambiguous.
+
+   Initial Data Connection Security
+
+      The initial state of the data connection MUST be 'Clear' (this is
+      the behaviour as indicated by [RFC-2228].)
+
+
+9. A Discussion of Negotiation Behaviour
+
+   9.1. The server's view of the control connection
+
+      A server MAY have a policy statement somewhere that might:
+
+         - Deny any command before TLS is negotiated (this might cause
+         problems if a SITE or some such command is required prior to
+         login)
+         - Deny certain commands before TLS is negotiated (such as USER,
+         PASS or ACCT)
+         - Deny insecure USER commands for certain users (e.g. not
+         ftp/anonymous)
+         - Deny secure USER commands for certain users (e.g.
+         ftp/anonymous)
+         - Define the level(s) of TLS to be allowed
+         - Define the CipherSuites allowed to be used (perhaps on a per
+         host/domain/...  basis)
+         - Allow TLS authentication as a substitute for local
+         authentication.
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand    FORMFEED[Page 9]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+         - Define data connection policies (see next section)
+
+         It is possible that the TLS negotiation may not be completed
+         satisfactorily for the server, in which case it can be one of
+         these states.
+
+            The TLS negotiation failed completely
+
+         In this case, the control connection should still be up in
+         unprotected mode and the server SHOULD issue an unprotected
+         '421' reply to end the session.
+
+            The TLS negotiation completed successfully, but the server
+            decides that the session parameters are not acceptable (e.g.
+            Distinguished Name in the client certificate is not
+            permitted to use the server)
+
+         In this case, the control connection should still be up in a
+         protected state, so the server MAY either continue to refuse to
+         service commands or issue a protected '421' reply and close the
+         connection.
+
+            The TLS negotiation failed during the TLS handshake
+
+         In this case, the control connection is in an unknown state and
+         the server SHOULD simply drop the control connection.
+
+      Server code will be responsible for implementing the required
+      policies and ensuring that the client is prevented from
+      circumventing the chosen security by refusing to service those
+      commands that are against policy.
+
+   9.2. The server's view of the data connection
+
+      The server can take one of four basic views of the data connection
+
+         1 - Don't allow encryption at all (in which case the PROT
+         command should not allow any value other than 'C' - if it is
+         allowed at all)
+         2 - Allow the client to choose protection or not
+         3 - Insist on data protection (in which case the PROT command
+         must be issued prior to the first attempted data transfer)
+         4 - Decide on one of the above three for each and every data
+         connection
+
+      The server SHOULD only check the status of the data protection
+      level (for options 3 and 4 above) on the actual command that will
+      initiate the data transfer (and not on the PORT or PASV).  The
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 10]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+      following commands, defined in [RFC-959] cause data connections to
+      be opened and thus may be rejected (before any 1xx) message due to
+      an incorrect PROT setting.
+
+
+         STOR
+         RETR
+         NLST
+         LIST
+         STOU
+         APPE
+
+
+      The reply to indicate that the PROT setting is incorrect is
+       '521 data connection cannot be opened with this PROT setting'
+      If the protection level indicates that TLS is required, then it
+      should be negotiated once the data connection is made.  Thus, the
+      '150' reply only states that the command can be used given the
+      current PROT level.  Should the server not like the TLS
+      negotiation then it will close the data port immediately and
+      follow the '150' command with a '522' reply indicating that the
+      TLS negotiation failed or was unacceptable.  (Note: this means
+      that the application can pass a standard list of CipherSuites to
+      the TLS layer for negotiation and review the one negotiated for
+      applicability in each instance).
+
+      It is quite reasonable for the server to insist that the data
+      connection uses a TLS cached session.  This might be a cache of a
+      previous data connection or of the control connection.  If this is
+      the reason for the the refusal to allow the data transfer then the
+      '522' reply should indicate this.
+      Note: this has an important impact on client design, but allows
+      servers to minimise the cycles used during TLS negotiation by
+      refusing to perform a full negotiation with a previously
+      authenticated client.
+
+      It should be noted that the TLS authentication of the server will
+      be authentication of the server host itself and not a user on the
+      server host.
+
+   9.3. The client's view of the control connection
+
+      In most cases it is likely that the client will be using TLS
+      because the server would refuse to interact insecurely.  To allow
+      for this, clients SHOULD be able to be flexible enough to manage
+      the securing of a session at the appropriate time and still allow
+      the user/server policies to dictate exactly when in the session
+      the security is negotiated.
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 11]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+      In the case where it is the client that is insisting on the
+      securing of the session, it will need to ensure that the
+      negotiations are all completed satisfactorily and will need to be
+      able to inform the user sensibly should the server not support, or
+      be prepared to use, the required security levels.
+
+      Clients SHOULD be coded in such a manner as to allow the timing of
+      the AUTH, PBSZ and PROT commands to be flexible and dictated by
+      the server.  It is quite reasonable for a server to refuse certain
+      commands prior to these commands, similarly it is quite possible
+      that a SITE or quoted command might be needed by a server prior to
+      the AUTH.  A client MUST allow a user to override the timing of
+      these commands to suit a specific server.
+      For example, a client SHOULD NOT insist on sending the AUTH as the
+      first command in a session, nor should it insist on issuing a
+      PBSZ, PROT pair directly after the AUTH.  This may well be the
+      default behaviour, but must be overridable by a user.
+
+      Note: The TLS negotiation may not be completed satisfactorily for
+      the client, in which case it will be in one of these states:
+
+            The TLS negotiation failed completely
+
+            In this case, the control connection should still be up in
+            unprotected mode and the client should issue an unprotected
+            QUIT command to end the session.
+
+            The TLS negotiation completed successfully, but the client
+            decides that the session parameters are not acceptable (e.g.
+            Distinguished Name in certificate is not the actual server
+            expected)
+
+            In this case, the control connection should still be up in a
+            protected state, so the client should issue a protected QUIT
+            command to end the session.
+
+            The TLS negotiation failed during the TLS handshake
+
+            In this case, the control connection is in an unknown state
+            and the client should simply drop the control connection.
+
+   9.4. The client's view of the data connection
+
+   Client security policies
+
+      Clients do not typically have 'policies' as such, instead they
+      rely on the user defining their actions and, to a certain extent,
+      are reactive to the server policy.  Thus a client will need to
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 12]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+      have commands that will allow the user to switch the protection
+      level of the data connection dynamically, however, there may be a
+      general 'policy' that attempts all LIST and NLST commands on a
+      Clear connection first (and automatically switches to Private if
+      it fails).  In this case there would need to be a user command
+      available to ensure that a given data transfer was not attempted
+      on an insecure data connection.
+
+      Clients also need to understand that the level of the PROT setting
+      is only checked for a particular data transfer after that transfer
+      has been requested.  Thus a refusal by the server to accept a
+      particular data transfer should not be read by the client as a
+      refusal to accept that data protection level in toto, as not only
+      may other data transfers be acceptable at that protection level,
+      but it is entirely possible that the same transfer may be accepted
+      at the same protection level at a later point in the session.
+
+      It should be noted that the TLS authentication of the client
+      should be authentication of a user on the client host and not the
+      client host itself.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 13]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+10. Who negotiates what, where and how
+
+   10.1. Do we protect at all ?
+
+      Client issues 'AUTH TLS', server accepts or rejects.
+      If server needs AUTH, then it refuses to accept certain commands
+      until it gets a successfully protected session.
+
+   10.2. What level of protection do we use on the Control connection ?
+
+      Decided entirely by the TLS CipherSuite negotiation.
+
+   10.3. Do we protect data connections in general ?
+
+      Client issues PROT command, server accepts or rejects.
+
+
+   10.4. Is protection required for a particular data transfer ?
+
+      A client would already have issued a PROT command if it required
+      the connection to be protected.
+      If a server needs to have the connection protected then it will
+      reply to the STOR/RETR/NLST/... command with a '522' indicating
+      that the current state of the data connection protection level is
+      not sufficient for that data transfer at that time.
+
+   10.5. What level of protection is required for a particular data
+   transfer ?
+
+      Decided entirely by the TLS CipherSuite negotiation.
+
+   Thus it can be seen that, for flexibility, it is desirable for the
+   FTP application to be able to interact with the TLS layer upon which
+   it sits to define and discover the exact TLS CipherSuites that are to
+   be/have been negotiated and make decisions accordingly.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 14]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+11. Timing Diagrams
+
+   11.1. Establishing a protected session
+
+           Client                                 Server
+  control          data                   data               control
+====================================================================
+
+                                                             socket()
+                                                             bind()
+  socket()
+  connect()  ----------------------------------------------> accept()
+            <----------------------------------------------  220
+  AUTH TLS   ---------------------------------------------->
+            <----------------------------------------------  234
+  TLSneg()  <----------------------------------------------> TLSneg()
+  PBSZ 0     ---------------------------------------------->
+            <----------------------------------------------  200
+  PROT P     ---------------------------------------------->
+            <----------------------------------------------  200
+  USER fred  ---------------------------------------------->
+            <----------------------------------------------  331
+  PASS pass  ---------------------------------------------->
+            <----------------------------------------------  230
+
+Note 1: the order of the PBSZ/PROT pair and the USER/PASS pair (with
+respect to each other) is not important (i.e. the USER/PASS can happen
+prior to the PBSZ/PROT - or indeed the server can refuse to allow a
+PBSZ/PROT pair until the USER/PASS pair has happened).
+
+Note 2: the PASS command might not be required at all (if the USER
+parameter and any client identity presented provide sufficient
+authentication).  The server would indicate this by issuing a '232'
+reply to the USER command instead of the '331' which requests a PASS
+from the client.
+
+Note 3: the AUTH command might not be the first command after the
+receipt of the 220 welcome message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 15]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+   11.2. A standard data transfer without protection.
+
+           Client                                 Server
+  control          data                   data               control
+====================================================================
+
+                   socket()
+                   bind()
+  PORT w,x,y,z,a,b ----------------------------------------->
+      <----------------------------------------------------- 200
+  STOR file ------------------------------------------------>
+                                          socket()
+                                          bind()
+      <----------------------------------------------------- 150
+                   accept() <-----------  connect()
+                   write()   -----------> read()
+                   close()   -----------> close()
+      <----------------------------------------------------- 226
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 16]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+   11.3. A firewall-friendly data transfer without protection
+
+           Client                                 Server
+  control          data                   data               control
+====================================================================
+
+  PASV -------------------------------------------------------->
+                                          socket()
+                                          bind()
+      <------------------------------------------ 227 (w,x,y,z,a,b)
+                   socket()
+  STOR file --------------------------------------------------->
+                   connect()  ----------> accept()
+      <-------------------------------------------------------- 150
+                   write()    ----------> read()
+                   close()    ----------> close()
+      <-------------------------------------------------------- 226
+
+
+    Note: Implementors should be aware that then connect()/accept()
+    function is performed prior to the receipt of the reply from the
+    STOR command. This contrasts with situation when (non-firewall-
+    friendly) PORT is used prior to the STOR, and the accept()/connect()
+    is performed after the reply from the aforementioned STOR has been
+    dealt with.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 17]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+   11.4. A standard data transfer with protection
+
+           Client                                 Server
+  control          data                   data               control
+====================================================================
+
+                   socket()
+                   bind()
+  PORT w,x,y,z,a,b -------------------------------------------->
+      <-------------------------------------------------------- 200
+  STOR file --------------------------------------------------->
+                                          socket()
+                                          bind()
+      <-------------------------------------------------------- 150
+                   accept()  <----------  connect()
+                   TLSneg()  <----------> TLSneg()
+                   TLSwrite() ----------> TLSread()
+                   TLSshutdown() -------> TLSshutdown()
+                   close()    ----------> close()
+      <-------------------------------------------------------- 226
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 18]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+   11.5. A firewall-friendly data transfer with protection
+
+           Client                                 Server
+  control          data                   data               control
+====================================================================
+
+  PASV -------------------------------------------------------->
+                                          socket()
+                                          bind()
+      <------------------------------------------ 227 (w,x,y,z,a,b)
+                   socket()
+  STOR file --------------------------------------------------->
+                   connect()  ----------> accept()
+      <-------------------------------------------------------- 150
+                   TLSneg()   <---------> TLSneg()
+                   TLSwrite()  ---------> TLSread()
+                   TLSshutdown() -------> TLSshutdown()
+                   close()     ---------> close()
+      <-------------------------------------------------------- 226
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 19]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+12. Discussion of the REIN command
+
+   The REIN command, defined in [RFC-959], allows the user to reset the
+   state of the FTP session.  From [RFC-959]:
+      REINITIALIZE (REIN)
+         This command terminates a USER, flushing all I/O and account
+         information, except to allow any transfer in progress to be
+         completed.  All parameters are reset to the default settings
+         and the control connection is left open.  This is identical to
+         the state in which a user finds himself immediately after the
+         control connection is opened.  A USER command may be expected
+         to follow.
+   When this command is processed by the server,  the TLS session(s)
+   MUST be cleared and the control and data connections revert to
+   unprotected, clear communications.  It MAY be acceptable to use
+   cached TLS sessions for subsequent connections, however a server MUST
+   not mandate this.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 20]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+13. Discussion of the STAT and ABOR commands
+
+   The ABOR and STAT commands and the use of TCP Urgent Pointers
+
+      [RFC-959] describes the use of Telnet commands (IP and DM) and the
+      TCP Urgent pointer to indicate the transmission of commands on the
+      control channel during the execution of a data transfer.  FTP uses
+      the Telnet Interrupt Process and Data Mark commands in conjunction
+      with Urgent data to preface two commands: ABOR (Abort Transfer)
+      and STAT (Status request).
+
+      The Urgent Pointer was used because in a Unix implementation the
+      receipt of a TCP packet marked as Urgent would result in the the
+      execution of the SIGURG interrupt handler.  This reliance on
+      interrupt handlers was necessary on systems which did not
+      implement select() or did not support multiple threads.  TLS does
+      not support the notion of Urgent data.
+
+      When TLS is implemented as a security method in FTP the server
+      SHOULD NOT rely on the use of SIGURG to process input on the
+      control channel during data transfers.  The client MUST send all
+      data including Telnet commands across the TLS session.  The TLS
+      session will be corrupted if any data is sent on a socket while
+      TLS is active.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 21]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+14. Security Considerations
+
+   This entire document deals with security considerations related to
+   the File Transfer Protocol.
+
+   14.1. Verification of Authentication tokens
+
+      14.1.1. Server Certificates
+
+         Although it is entirely an implementation decision, it is
+         recommended that certificates used for server authentication of
+         the TLS session contain the server identification information
+         in a similar manner to those used for http servers.  (see
+         [RFC-2818])
+
+         Similarly, it is recommended that the certificate used for
+         server authentication of Data connections is the same
+         certificate as that used for the corresponding Control
+         connection.
+
+      14.1.2. Client Certificates
+
+         - Deciding which client certificates to allow and defining
+         which fields define what authentication information is entirely
+         a server implementation issue.
+
+         - It is also server implementation issue to decide if the
+         authentication token presented for the data connection must
+         match the one used for the corresponding control connection.
+
+   14.2. Addressing FTP Security Considerations [RFC-2577]
+
+      14.2.1. Bounce Attack
+
+         A bounce attack should be harder in a secured FTP environment
+         because:
+
+            - The FTP server that is being used to initiate a false
+            connection will always be a 'server' in the TLS context.
+            Therefore, only services that act as 'clients' in the TLS
+            context could be vulnerable.  This would be a counter-
+            intuitive way to implement TLS on a service.
+
+            - The FTP server would detect that the authentication
+            credentials for the data connection are not the same as
+            those for the control connection, thus the server policies
+            COULD be set to drop the data connection.
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 22]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+            - Genuine users are less likely to initiate such attacks
+            when the authentication is strong and malicious users are
+            less likely to gain access to the FTP server if the
+            authentication is not easily subverted (password guessing,
+            network tracing, etc...)
+
+      14.2.2. Restricting Access
+
+         This document presents a strong mechanism for solving the issue
+         raised in this section.
+
+      14.2.3. Protecting Passwords
+
+         The twin solutions of strong authentication and data
+         confidentiality ensure that this is not an issue when TLS is
+         used to protect the control session.
+
+      14.2.4. Privacy
+
+         The TLS protocol ensures data confidentiality by encryption.
+         Privacy (e.g. access to download logs, user profile
+         information, etc...) is outside the scope of this document (and
+         [RFC-2577] presumably)
+
+      14.2.5. Protecting Usernames
+
+         This is not an issue when TLS is used as the primary
+         authentication mechanism.
+
+      14.2.6. Port Stealing
+
+         This proposal will do little for the Denial of Service element
+         of this section, however, strong authentication on the data
+         connection will prevent unauthorised connections retrieving or
+         submitting files.
+
+      14.2.7. Software-Base Security Problems
+
+         Nothing in this proposal will affect the discussion in this
+         section.
+
+
+15. IANA Considerations
+
+   {FTP-PORT} - The port assigned to the FTP control connection is 21.
+
+16. Other Parameters
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 23]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+   {TLS-PARM} - The parameter for the AUTH command to indicate that TLS
+   is required.  To request the TLS protocol in accordance with this
+   document, the client MUST use 'TLS'
+
+      To maintain backward compatability with older versions of this
+      document, the server SHOULD accept 'TLS-C' as a synonym for 'TLS'
+
+         Note - [RFC-2228] states that these parameters are case-
+         insensitive.
+
+
+17. Network Management
+
+   NONE
+
+
+18. Internationalization
+
+   NONE
+
+
+19. Scalability & Limits
+
+   There are no issues other than those concerned with the ability of
+   the server to refuse to have a complete TLS negotiation for each and
+   every data connection, which will allow servers to retain throughput
+   whilst using cycles only when necessary.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 24]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+20. Applicability
+
+   This mechanism is generally applicable as a mechanism for securing
+   the FTP protocol.  It is unlikely that anonymous FTP clients or
+   servers will require such security (although some might like the
+   authentication features without the confidentiality).
+
+
+21. Acknowledgements
+
+   o Netscape Communications Corporation for the original SSL protocol.
+
+   o Eric Young for the SSLeay libraries.
+
+   o University of California, Berkley for the original implementations
+   of FTP and ftpd on which the initial implementation of these
+   extensions were layered.
+
+   o IETF CAT working group.
+
+   o IETF TLS working group.
+
+   o IETF FTPEXT working group.
+
+   o Jeff Altman for the ABOR and STAT discussion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 25]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+22. References
+
+   [RFC-959] J. Postel, "File Transfer Protocol"
+      RFC 959, October 1985.
+
+   [RFC-1579] S. Bellovin, "Firewall-Friendly FTP"
+      RFC 1579, February 1994.
+
+   [RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate
+   Requirement Levels"
+      RFC 2119, March 1997.
+
+   [RFC-2222] J. Myers, "Simple Authentication and Security Layer"
+      RFC 2222, October 1997.
+
+   [RFC-2228] M. Horowitz, S. Lunt, "FTP Security Extensions"
+      RFC 2228, October 1997.
+
+   [RFC-2246] T. Dierks, C. Allen, "The TLS Protocol Version 1.0"
+      RFC 2246, January 1999.
+
+   [RFC-2389] P Hethmon, R.Elz, "Feature Negotiation Mechanism for the
+   File Transfer Protocol"
+      RFC 2389, August 1998.
+
+   [RFC-2487] P Hoffman, "SMTP Service Extension for Secure SMTP over
+   TLS"
+      RFC 2487, January 1999.
+
+   [RFC-2577] M Allman, S Ostermann, "FTP Security Considerations"
+      RFC 2577, May 1999.
+
+   [RFC-2817] R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1"
+      RFC 2817, May 2000.
+
+   [RFC-2818] E. Rescorla,  "HTTP Over TLS"
+      RFC 2818, May 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 26]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+23. Authors' Contact Addresses
+
+The FTP-TLS draft information site is at http://www.ford-
+hutchinson.com/~fh-1-pfh/ftps-ext.html
+
+
+Please send comments to Paul Ford-Hutchinson at the address below
+
+        Tim Hudson                  Paul Ford-Hutchinson
+           RSA Data Security           IBM UK Ltd
+             Australia Pty Ltd         PO Box 31
+                                       Birmingham Road
+                                       Warwick
+                                       United Kingdom
+  tel -   [phone]             [phone]
+  fax -   [phone]             [phone]
+email - [e-mail]    [e-mail]
+
+        Martin Carpenter            Eric Murray
+           Verisign Ltd                Wave Systems Inc.
+email -  [e-mail]    [e-mail]
+
+        Volker Wiegand
+           SuSE Linux
+email -  [e-mail]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 27]
+
+
+
+
+
+Internet-Draft            Secure FTP using TLS           2nd April, 2002
+
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+This document expires on 2nd October, 2002
+
+
+
+
+Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand   FORMFEED[Page 28]
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/rfcs/rfc2068.txt	Tue Jul 13 01:35:15 2004 +0000
@@ -0,0 +1,9075 @@
+
+
+
+
+
+
+Network Working Group                                      R. Fielding
+Request for Comments: 2068                                   UC Irvine
+Category: Standards Track                                    J. Gettys
+                                                              J. Mogul
+                                                                   DEC
+                                                            H. Frystyk
+                                                        T. Berners-Lee
+                                                               MIT/LCS
+                                                          January 1997
+
+
+                Hypertext Transfer Protocol -- HTTP/1.1
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   The Hypertext Transfer Protocol (HTTP) is an application-level
+   protocol for distributed, collaborative, hypermedia information
+   systems. It is a generic, stateless, object-oriented protocol which
+   can be used for many tasks, such as name servers and distributed
+   object management systems, through extension of its request methods.
+   A feature of HTTP is the typing and negotiation of data
+   representation, allowing systems to be built independently of the
+   data being transferred.
+
+   HTTP has been in use by the World-Wide Web global information
+   initiative since 1990. This specification defines the protocol
+   referred to as "HTTP/1.1".
+
+Table of Contents
+
+   1 Introduction.............................................7
+    1.1 Purpose ..............................................7
+    1.2 Requirements .........................................7
+    1.3 Terminology ..........................................8
+    1.4 Overall Operation ...................................11
+   2 Notational Conventions and Generic Grammar..............13
+    2.1 Augmented BNF .......................................13
+    2.2 Basic Rules .........................................15
+   3 Protocol Parameters.....................................17
+    3.1 HTTP Version ........................................17
+
+
+
+Fielding, et. al.           Standards Track                     [Page 1]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+    3.2 Uniform Resource Identifiers ........................18
+     3.2.1 General Syntax ...................................18
+     3.2.2 http URL .........................................19
+     3.2.3 URI Comparison ...................................20
+    3.3 Date/Time Formats ...................................21
+     3.3.1 Full Date ........................................21
+     3.3.2 Delta Seconds ....................................22
+    3.4 Character Sets ......................................22
+    3.5 Content Codings .....................................23
+    3.6 Transfer Codings ....................................24
+    3.7 Media Types .........................................25
+     3.7.1 Canonicalization and Text Defaults ...............26
+     3.7.2 Multipart Types ..................................27
+    3.8 Product Tokens ......................................28
+    3.9 Quality Values ......................................28
+    3.10 Language Tags ......................................28
+    3.11 Entity Tags ........................................29
+    3.12 Range Units ........................................30
+   4 HTTP Message............................................30
+    4.1 Message Types .......................................30
+    4.2 Message Headers .....................................31
+    4.3 Message Body ........................................32
+    4.4 Message Length ......................................32
+    4.5 General Header Fields ...............................34
+   5 Request.................................................34
+    5.1 Request-Line ........................................34
+     5.1.1 Method ...........................................35
+     5.1.2 Request-URI ......................................35
+    5.2 The Resource Identified by a Request ................37
+    5.3 Request Header Fields ...............................37
+   6 Response................................................38
+    6.1 Status-Line .........................................38
+     6.1.1 Status Code and Reason Phrase ....................39
+    6.2 Response Header Fields ..............................41
+   7 Entity..................................................41
+    7.1 Entity Header Fields ................................41
+    7.2 Entity Body .........................................42
+     7.2.1 Type .............................................42
+     7.2.2 Length ...........................................43
+   8 Connections.............................................43
+    8.1 Persistent Connections ..............................43
+     8.1.1 Purpose ..........................................43
+     8.1.2 Overall Operation ................................44
+     8.1.3 Proxy Servers ....................................45
+     8.1.4 Practical Considerations .........................45
+    8.2 Message Transmission Requirements ...................46
+   9 Method Definitions......................................48
+    9.1 Safe and Idempotent Methods .........................48
+
+
+
+Fielding, et. al.           Standards Track                     [Page 2]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+     9.1.1 Safe Methods .....................................48
+     9.1.2 Idempotent Methods ...............................49
+    9.2 OPTIONS .............................................49
+    9.3 GET .................................................50
+    9.4 HEAD ................................................50
+    9.5 POST ................................................51
+    9.6 PUT .................................................52
+    9.7 DELETE ..............................................53
+    9.8 TRACE ...............................................53
+   10 Status Code Definitions................................53
+    10.1 Informational 1xx ..................................54
+     10.1.1 100 Continue ....................................54
+     10.1.2 101 Switching Protocols .........................54
+    10.2 Successful 2xx .....................................54
+     10.2.1 200 OK ..........................................54
+     10.2.2 201 Created .....................................55
+     10.2.3 202 Accepted ....................................55
+     10.2.4 203 Non-Authoritative Information ...............55
+     10.2.5 204 No Content ..................................55
+     10.2.6 205 Reset Content ...............................56
+     10.2.7 206 Partial Content .............................56
+    10.3 Redirection 3xx ....................................56
+     10.3.1 300 Multiple Choices ............................57
+     10.3.2 301 Moved Permanently ...........................57
+     10.3.3 302 Moved Temporarily ...........................58
+     10.3.4 303 See Other ...................................58
+     10.3.5 304 Not Modified ................................58
+     10.3.6 305 Use Proxy ...................................59
+    10.4 Client Error 4xx ...................................59
+     10.4.1 400 Bad Request .................................60
+     10.4.2 401 Unauthorized ................................60
+     10.4.3 402 Payment Required ............................60
+     10.4.4 403 Forbidden ...................................60
+     10.4.5 404 Not Found ...................................60
+     10.4.6 405 Method Not Allowed ..........................61
+     10.4.7 406 Not Acceptable ..............................61
+     10.4.8 407 Proxy Authentication Required ...............61
+     10.4.9 408 Request Timeout .............................62
+     10.4.10 409 Conflict ...................................62
+     10.4.11 410 Gone .......................................62
+     10.4.12 411 Length Required ............................63
+     10.4.13 412 Precondition Failed ........................63
+     10.4.14 413 Request Entity Too Large ...................63
+     10.4.15 414 Request-URI Too Long .......................63
+     10.4.16 415 Unsupported Media Type .....................63
+    10.5 Server Error 5xx ...................................64
+     10.5.1 500 Internal Server Error .......................64
+     10.5.2 501 Not Implemented .............................64
+
+
+
+Fielding, et. al.           Standards Track                     [Page 3]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+     10.5.3 502 Bad Gateway .................................64
+     10.5.4 503 Service Unavailable .........................64
+     10.5.5 504 Gateway Timeout .............................64
+     10.5.6 505 HTTP Version Not Supported ..................65
+   11 Access Authentication..................................65
+    11.1 Basic Authentication Scheme ........................66
+    11.2 Digest Authentication Scheme .......................67
+   12 Content Negotiation....................................67
+    12.1 Server-driven Negotiation ..........................68
+    12.2 Agent-driven Negotiation ...........................69
+    12.3 Transparent Negotiation ............................70
+   13 Caching in HTTP........................................70
+     13.1.1 Cache Correctness ...............................72
+     13.1.2 Warnings ........................................73
+     13.1.3 Cache-control Mechanisms ........................74
+     13.1.4 Explicit User Agent Warnings ....................74
+     13.1.5 Exceptions to the Rules and Warnings ............75
+     13.1.6 Client-controlled Behavior ......................75
+    13.2 Expiration Model ...................................75
+     13.2.1 Server-Specified Expiration .....................75
+     13.2.2 Heuristic Expiration ............................76
+     13.2.3 Age Calculations ................................77
+     13.2.4 Expiration Calculations .........................79
+     13.2.5 Disambiguating Expiration Values ................80
+     13.2.6 Disambiguating Multiple Responses ...............80
+    13.3 Validation Model ...................................81
+     13.3.1 Last-modified Dates .............................82
+     13.3.2 Entity Tag Cache Validators .....................82
+     13.3.3 Weak and Strong Validators ......................82
+     13.3.4 Rules for When to Use Entity Tags and Last-
+     modified Dates..........................................85
+     13.3.5 Non-validating Conditionals .....................86
+    13.4 Response Cachability ...............................86
+    13.5 Constructing Responses From Caches .................87
+     13.5.1 End-to-end and Hop-by-hop Headers ...............88
+     13.5.2 Non-modifiable Headers ..........................88
+     13.5.3 Combining Headers ...............................89
+     13.5.4 Combining Byte Ranges ...........................90
+    13.6 Caching Negotiated Responses .......................90
+    13.7 Shared and Non-Shared Caches .......................91
+    13.8 Errors or Incomplete Response Cache Behavior .......91
+    13.9 Side Effects of GET and HEAD .......................92
+    13.10 Invalidation After Updates or Deletions ...........92
+    13.11 Write-Through Mandatory ...........................93
+    13.12 Cache Replacement .................................93
+    13.13 History Lists .....................................93
+   14 Header Field Definitions...............................94
+    14.1 Accept .............................................95
+
+
+
+Fielding, et. al.           Standards Track                     [Page 4]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+    14.2 Accept-Charset .....................................97
+    14.3 Accept-Encoding ....................................97
+    14.4 Accept-Language ....................................98
+    14.5 Accept-Ranges ......................................99
+    14.6 Age ................................................99
+    14.7 Allow .............................................100
+    14.8 Authorization .....................................100
+    14.9 Cache-Control .....................................101
+     14.9.1 What is Cachable ...............................103
+     14.9.2 What May be Stored by Caches ...................103
+     14.9.3 Modifications of the Basic Expiration Mechanism 104
+     14.9.4 Cache Revalidation and Reload Controls .........105
+     14.9.5 No-Transform Directive .........................107
+     14.9.6 Cache Control Extensions .......................108
+    14.10 Connection .......................................109
+    14.11 Content-Base .....................................109
+    14.12 Content-Encoding .................................110
+    14.13 Content-Language .................................110
+    14.14 Content-Length ...................................111
+    14.15 Content-Location .................................112
+    14.16 Content-MD5 ......................................113
+    14.17 Content-Range ....................................114
+    14.18 Content-Type .....................................116
+    14.19 Date .............................................116
+    14.20 ETag .............................................117
+    14.21 Expires ..........................................117
+    14.22 From .............................................118
+    14.23 Host .............................................119
+    14.24 If-Modified-Since ................................119
+    14.25 If-Match .........................................121
+    14.26 If-None-Match ....................................122
+    14.27 If-Range .........................................123
+    14.28 If-Unmodified-Since ..............................124
+    14.29 Last-Modified ....................................124
+    14.30 Location .........................................125
+    14.31 Max-Forwards .....................................125
+    14.32 Pragma ...........................................126
+    14.33 Proxy-Authenticate ...............................127
+    14.34 Proxy-Authorization ..............................127
+    14.35 Public ...........................................127
+    14.36 Range ............................................128
+     14.36.1 Byte Ranges ...................................128
+     14.36.2 Range Retrieval Requests ......................130
+    14.37 Referer ..........................................131
+    14.38 Retry-After ......................................131
+    14.39 Server ...........................................132
+    14.40 Transfer-Encoding ................................132
+    14.41 Upgrade ..........................................132
+
+
+
+Fielding, et. al.           Standards Track                     [Page 5]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+    14.42 User-Agent .......................................134
+    14.43 Vary .............................................134
+    14.44 Via ..............................................135
+    14.45 Warning ..........................................137
+    14.46 WWW-Authenticate .................................139
+   15 Security Considerations...............................139
+    15.1 Authentication of Clients .........................139
+    15.2 Offering a Choice of Authentication Schemes .......140
+    15.3 Abuse of Server Log Information ...................141
+    15.4 Transfer of Sensitive Information .................141
+    15.5 Attacks Based On File and Path Names ..............142
+    15.6 Personal Information ..............................143
+    15.7 Privacy Issues Connected to Accept Headers ........143
+    15.8 DNS Spoofing ......................................144
+    15.9 Location Headers and Spoofing .....................144
+   16 Acknowledgments.......................................144
+   17 References............................................146
+   18 Authors' Addresses....................................149
+   19 Appendices............................................150
+    19.1 Internet Media Type message/http ..................150
+    19.2 Internet Media Type multipart/byteranges ..........150
+    19.3 Tolerant Applications .............................151
+    19.4 Differences Between HTTP Entities and
+    MIME Entities...........................................152
+     19.4.1 Conversion to Canonical Form ...................152
+     19.4.2 Conversion of Date Formats .....................153
+     19.4.3 Introduction of Content-Encoding ...............153
+     19.4.4 No Content-Transfer-Encoding ...................153
+     19.4.5 HTTP Header Fields in Multipart Body-Parts .....153
+     19.4.6 Introduction of Transfer-Encoding ..............154
+     19.4.7 MIME-Version ...................................154
+    19.5 Changes from HTTP/1.0 .............................154
+     19.5.1 Changes to Simplify Multi-homed Web Servers and
+     Conserve IP Addresses .................................155
+    19.6 Additional Features ...............................156
+     19.6.1 Additional Request Methods .....................156
+     19.6.2 Additional Header Field Definitions ............156
+    19.7 Compatibility with Previous Versions ..............160
+     19.7.1 Compatibility with HTTP/1.0 Persistent
+     Connections............................................161
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                     [Page 6]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+1 Introduction
+
+1.1 Purpose
+
+   The Hypertext Transfer Protocol (HTTP) is an application-level
+   protocol for distributed, collaborative, hypermedia information
+   systems. HTTP has been in use by the World-Wide Web global
+   information initiative since 1990. The first version of HTTP,
+   referred to as HTTP/0.9, was a simple protocol for raw data transfer
+   across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved
+   the protocol by allowing messages to be in the format of MIME-like
+   messages, containing metainformation about the data transferred and
+   modifiers on the request/response semantics. However, HTTP/1.0 does
+   not sufficiently take into consideration the effects of hierarchical
+   proxies, caching, the need for persistent connections, and virtual
+   hosts. In addition, the proliferation of incompletely-implemented
+   applications calling themselves "HTTP/1.0" has necessitated a
+   protocol version change in order for two communicating applications
+   to determine each other's true capabilities.
+
+   This specification defines the protocol referred to as "HTTP/1.1".
+   This protocol includes more stringent requirements than HTTP/1.0 in
+   order to ensure reliable implementation of its features.
+
+   Practical information systems require more functionality than simple
+   retrieval, including search, front-end update, and annotation. HTTP
+   allows an open-ended set of methods that indicate the purpose of a
+   request. It builds on the discipline of reference provided by the
+   Uniform Resource Identifier (URI) [3][20], as a location (URL) [4] or
+   name (URN) , for indicating the resource to which a method is to be
+   applied. Messages are passed in a format similar to that used by
+   Internet mail as defined by the Multipurpose Internet Mail Extensions
+   (MIME).
+
+   HTTP is also used as a generic protocol for communication between
+   user agents and proxies/gateways to other Internet systems, including
+   those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2],
+   and WAIS [10] protocols. In this way, HTTP allows basic hypermedia
+   access to resources available from diverse applications.
+
+1.2 Requirements
+
+   This specification uses the same words as RFC 1123 [8] for defining
+   the significance of each particular requirement. These words are:
+
+   MUST
+      This word or the adjective "required" means that the item is an
+      absolute requirement of the specification.
+
+
+
+Fielding, et. al.           Standards Track                     [Page 7]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   SHOULD
+      This word or the adjective "recommended" means that there may
+      exist valid reasons in particular circumstances to ignore this
+      item, but the full implications should be understood and the case
+      carefully weighed before choosing a different course.
+
+   MAY
+      This word or the adjective "optional" means that this item is
+      truly optional. One vendor may choose to include the item because
+      a particular marketplace requires it or because it enhances the
+      product, for example; another vendor may omit the same item.
+
+   An implementation is not compliant if it fails to satisfy one or more
+   of the MUST requirements for the protocols it implements. An
+   implementation that satisfies all the MUST and all the SHOULD
+   requirements for its protocols is said to be "unconditionally
+   compliant"; one that satisfies all the MUST requirements but not all
+   the SHOULD requirements for its protocols is said to be
+   "conditionally compliant."
+
+1.3 Terminology
+
+   This specification uses a number of terms to refer to the roles
+   played by participants in, and objects of, the HTTP communication.
+
+   connection
+      A transport layer virtual circuit established between two programs
+      for the purpose of communication.
+
+   message
+      The basic unit of HTTP communication, consisting of a structured
+      sequence of octets matching the syntax defined in section 4 and
+      transmitted via the connection.
+
+   request
+      An HTTP request message, as defined in section 5.
+
+   response
+      An HTTP response message, as defined in section 6.
+
+   resource
+      A network data object or service that can be identified by a URI,
+      as defined in section 3.2. Resources may be available in multiple
+      representations (e.g. multiple languages, data formats, size,
+      resolutions) or vary in other ways.
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                     [Page 8]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   entity
+      The information transferred as the payload of a request or
+      response. An entity consists of metainformation in the form of
+      entity-header fields and content in the form of an entity-body, as
+      described in section 7.
+
+   representation
+      An entity included with a response that is subject to content
+      negotiation, as described in section 12. There may exist multiple
+      representations associated with a particular response status.
+
+   content negotiation
+      The mechanism for selecting the appropriate representation when
+      servicing a request, as described in section 12. The
+      representation of entities in any response can be negotiated
+      (including error responses).
+
+   variant
+      A resource may have one, or more than one, representation(s)
+      associated with it at any given instant. Each of these
+      representations is termed a `variant.' Use of the term `variant'
+      does not necessarily imply that the resource is subject to content
+      negotiation.
+
+   client
+      A program that establishes connections for the purpose of sending
+      requests.
+
+   user agent
+      The client which initiates a request. These are often browsers,
+      editors, spiders (web-traversing robots), or other end user tools.
+
+   server
+      An application program that accepts connections in order to
+      service requests by sending back responses. Any given program may
+      be capable of being both a client and a server; our use of these
+      terms refers only to the role being performed by the program for a
+      particular connection, rather than to the program's capabilities
+      in general.  Likewise, any server may act as an origin server,
+      proxy, gateway, or tunnel, switching behavior based on the nature
+      of each request.
+
+   origin server
+      The server on which a given resource resides or is to be created.
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                     [Page 9]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   proxy
+      An intermediary program which acts as both a server and a client
+      for the purpose of making requests on behalf of other clients.
+      Requests are serviced internally or by passing them on, with
+      possible translation, to other servers. A proxy must implement
+      both the client and server requirements of this specification.
+
+   gateway
+      A server which acts as an intermediary for some other server.
+      Unlike a proxy, a gateway receives requests as if it were the
+      origin server for the requested resource; the requesting client
+      may not be aware that it is communicating with a gateway.
+
+   tunnel
+      An intermediary program which is acting as a blind relay between
+      two connections. Once active, a tunnel is not considered a party
+      to the HTTP communication, though the tunnel may have been
+      initiated by an HTTP request. The tunnel ceases to exist when both
+      ends of the relayed connections are closed.
+
+   cache
+      A program's local store of response messages and the subsystem
+      that controls its message storage, retrieval, and deletion. A
+      cache stores cachable responses in order to reduce the response
+      time and network bandwidth consumption on future, equivalent
+      requests. Any client or server may include a cache, though a cache
+      cannot be used by a server that is acting as a tunnel.
+
+   cachable
+      A response is cachable if a cache is allowed to store a copy of
+      the response message for use in answering subsequent requests. The
+      rules for determining the cachability of HTTP responses are
+      defined in section 13. Even if a resource is cachable, there may
+      be additional constraints on whether a cache can use the cached
+      copy for a particular request.
+
+   first-hand
+      A response is first-hand if it comes directly and without
+      unnecessary delay from the origin server, perhaps via one or more
+      proxies. A response is also first-hand if its validity has just
+      been checked directly with the origin server.
+
+   explicit expiration time
+      The time at which the origin server intends that an entity should
+      no longer be returned by a cache without further validation.
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 10]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   heuristic expiration time
+      An expiration time assigned by a cache when no explicit expiration
+      time is available.
+
+   age
+      The age of a response is the time since it was sent by, or
+      successfully validated with, the origin server.
+
+   freshness lifetime
+      The length of time between the generation of a response and its
+      expiration time.
+
+   fresh
+      A response is fresh if its age has not yet exceeded its freshness
+      lifetime.
+
+   stale
+      A response is stale if its age has passed its freshness lifetime.
+
+   semantically transparent
+      A cache behaves in a "semantically transparent" manner, with
+      respect to a particular response, when its use affects neither the
+      requesting client nor the origin server, except to improve
+      performance. When a cache is semantically transparent, the client
+      receives exactly the same response (except for hop-by-hop headers)
+      that it would have received had its request been handled directly
+      by the origin server.
+
+   validator
+      A protocol element (e.g., an entity tag or a Last-Modified time)
+      that is used to find out whether a cache entry is an equivalent
+      copy of an entity.
+
+1.4 Overall Operation
+
+   The HTTP protocol is a request/response protocol. A client sends a
+   request to the server in the form of a request method, URI, and
+   protocol version, followed by a MIME-like message containing request
+   modifiers, client information, and possible body content over a
+   connection with a server. The server responds with a status line,
+   including the message's protocol version and a success or error code,
+   followed by a MIME-like message containing server information, entity
+   metainformation, and possible entity-body content. The relationship
+   between HTTP and MIME is described in appendix 19.4.
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 11]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Most HTTP communication is initiated by a user agent and consists of
+   a request to be applied to a resource on some origin server. In the
+   simplest case, this may be accomplished via a single connection (v)
+   between the user agent (UA) and the origin server (O).
+
+             request chain ------------------------>
+          UA -------------------v------------------- O
+             <----------------------- response chain
+
+   A more complicated situation occurs when one or more intermediaries
+   are present in the request/response chain. There are three common
+   forms of intermediary: proxy, gateway, and tunnel. A proxy is a
+   forwarding agent, receiving requests for a URI in its absolute form,
+   rewriting all or part of the message, and forwarding the reformatted
+   request toward the server identified by the URI. A gateway is a
+   receiving agent, acting as a layer above some other server(s) and, if
+   necessary, translating the requests to the underlying server's
+   protocol. A tunnel acts as a relay point between two connections
+   without changing the messages; tunnels are used when the
+   communication needs to pass through an intermediary (such as a
+   firewall) even when the intermediary cannot understand the contents
+   of the messages.
+
+             request chain -------------------------------------->
+          UA -----v----- A -----v----- B -----v----- C -----v----- O
+             <------------------------------------- response chain
+
+   The figure above shows three intermediaries (A, B, and C) between the
+   user agent and origin server. A request or response message that
+   travels the whole chain will pass through four separate connections.
+   This distinction is important because some HTTP communication options
+   may apply only to the connection with the nearest, non-tunnel
+   neighbor, only to the end-points of the chain, or to all connections
+   along the chain.  Although the diagram is linear, each participant
+   may be engaged in multiple, simultaneous communications. For example,
+   B may be receiving requests from many clients other than A, and/or
+   forwarding requests to servers other than C, at the same time that it
+   is handling A's request.
+
+   Any party to the communication which is not acting as a tunnel may
+   employ an internal cache for handling requests. The effect of a cache
+   is that the request/response chain is shortened if one of the
+   participants along the chain has a cached response applicable to that
+   request. The following illustrates the resulting chain if B has a
+   cached copy of an earlier response from O (via C) for a request which
+   has not been cached by UA or A.
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 12]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+             request chain ---------->
+          UA -----v----- A -----v----- B - - - - - - C - - - - - - O
+             <--------- response chain
+
+   Not all responses are usefully cachable, and some requests may
+   contain modifiers which place special requirements on cache behavior.
+   HTTP requirements for cache behavior and cachable responses are
+   defined in section 13.
+
+   In fact, there are a wide variety of architectures and configurations
+   of caches and proxies currently being experimented with or deployed
+   across the World Wide Web; these systems include national hierarchies
+   of proxy caches to save transoceanic bandwidth, systems that
+   broadcast or multicast cache entries, organizations that distribute
+   subsets of cached data via CD-ROM, and so on. HTTP systems are used
+   in corporate intranets over high-bandwidth links, and for access via
+   PDAs with low-power radio links and intermittent connectivity. The
+   goal of HTTP/1.1 is to support the wide diversity of configurations
+   already deployed while introducing protocol constructs that meet the
+   needs of those who build web applications that require high
+   reliability and, failing that, at least reliable indications of
+   failure.
+
+   HTTP communication usually takes place over TCP/IP connections. The
+   default port is TCP 80, but other ports can be used. This does not
+   preclude HTTP from being implemented on top of any other protocol on
+   the Internet, or on other networks. HTTP only presumes a reliable
+   transport; any protocol that provides such guarantees can be used;
+   the mapping of the HTTP/1.1 request and response structures onto the
+   transport data units of the protocol in question is outside the scope
+   of this specification.
+
+   In HTTP/1.0, most implementations used a new connection for each
+   request/response exchange. In HTTP/1.1, a connection may be used for
+   one or more request/response exchanges, although connections may be
+   closed for a variety of reasons (see section 8.1).
+
+2 Notational Conventions and Generic Grammar
+
+2.1 Augmented BNF
+
+   All of the mechanisms specified in this document are described in
+   both prose and an augmented Backus-Naur Form (BNF) similar to that
+   used by RFC 822 [9]. Implementers will need to be familiar with the
+   notation in order to understand this specification. The augmented BNF
+   includes the following constructs:
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 13]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+name = definition
+     The name of a rule is simply the name itself (without any enclosing
+     "<" and ">") and is separated from its definition by the equal "="
+     character. Whitespace is only significant in that indentation of
+     continuation lines is used to indicate a rule definition that spans
+     more than one line. Certain basic rules are in uppercase, such as
+     SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used
+     within definitions whenever their presence will facilitate
+     discerning the use of rule names.
+
+"literal"
+     Quotation marks surround literal text. Unless stated otherwise, the
+          text is case-insensitive.
+
+rule1 | rule2
+     Elements separated by a bar ("|") are alternatives, e.g., "yes |
+     no" will accept yes or no.
+
+(rule1 rule2)
+     Elements enclosed in parentheses are treated as a single element.
+     Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
+     foo elem" and "elem bar elem".
+
+*rule
+     The character "*" preceding an element indicates repetition. The
+     full form is "<n>*<m>element" indicating at least <n> and at most
+     <m> occurrences of element. Default values are 0 and infinity so
+     that "*(element)" allows any number, including zero; "1*element"
+     requires at least one; and "1*2element" allows one or two.
+
+[rule]
+     Square brackets enclose optional elements; "[foo bar]" is
+     equivalent to "*1(foo bar)".
+
+N rule
+     Specific repetition: "<n>(element)" is equivalent to
+     "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
+     Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
+     alphabetic characters.
+
+#rule
+     A construct "#" is defined, similar to "*", for defining lists of
+     elements. The full form is "<n>#<m>element " indicating at least
+     <n> and at most <m> elements, each separated by one or more commas
+     (",") and optional linear whitespace (LWS). This makes the usual
+     form of lists very easy; a rule such as "( *LWS element *( *LWS ","
+     *LWS element )) " can be shown as "1#element". Wherever this
+     construct is used, null elements are allowed, but do not contribute
+
+
+
+Fielding, et. al.           Standards Track                    [Page 14]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+     to the count of elements present.  That is, "(element), , (element)
+     " is permitted, but counts as only two elements. Therefore, where
+     at least one element is required, at least one non-null element
+     must be present. Default values are 0 and infinity so that
+     "#element" allows any number, including zero; "1#element" requires
+     at least one; and "1#2element" allows one or two.
+
+; comment
+     A semi-colon, set off some distance to the right of rule text,
+     starts a comment that continues to the end of line. This is a
+     simple way of including useful notes in parallel with the
+     specifications.
+
+implied *LWS
+     The grammar described by this specification is word-based. Except
+     where noted otherwise, linear whitespace (LWS) can be included
+     between any two adjacent words (token or quoted-string), and
+     between adjacent tokens and delimiters (tspecials), without
+     changing the interpretation of a field. At least one delimiter
+     (tspecials) must exist between any two tokens, since they would
+     otherwise be interpreted as a single token.
+
+2.2 Basic Rules
+
+   The following rules are used throughout this specification to
+   describe basic parsing constructs. The US-ASCII coded character set
+   is defined by ANSI X3.4-1986 [21].
+
+          OCTET          = <any 8-bit sequence of data>
+          CHAR           = <any US-ASCII character (octets 0 - 127)>
+          UPALPHA        = <any US-ASCII uppercase letter "A".."Z">
+          LOALPHA        = <any US-ASCII lowercase letter "a".."z">
+          ALPHA          = UPALPHA | LOALPHA
+          DIGIT          = <any US-ASCII digit "0".."9">
+          CTL            = <any US-ASCII control character
+                           (octets 0 - 31) and DEL (127)>
+          CR             = <US-ASCII CR, carriage return (13)>
+          LF             = <US-ASCII LF, linefeed (10)>
+          SP             = <US-ASCII SP, space (32)>
+          HT             = <US-ASCII HT, horizontal-tab (9)>
+          <">            = <US-ASCII double-quote mark (34)>
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 15]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
+   protocol elements except the entity-body (see appendix 19.3 for
+   tolerant applications). The end-of-line marker within an entity-body
+   is defined by its associated media type, as described in section 3.7.
+
+          CRLF           = CR LF
+
+   HTTP/1.1 headers can be folded onto multiple lines if the
+   continuation line begins with a space or horizontal tab. All linear
+   white space, including folding, has the same semantics as SP.
+
+          LWS            = [CRLF] 1*( SP | HT )
+
+   The TEXT rule is only used for descriptive field contents and values
+   that are not intended to be interpreted by the message parser. Words
+   of *TEXT may contain characters from character sets other than ISO
+   8859-1 [22] only when encoded according to the rules of RFC 1522
+   [14].
+
+          TEXT           = <any OCTET except CTLs,
+                           but including LWS>
+
+   Hexadecimal numeric characters are used in several protocol elements.
+
+          HEX            = "A" | "B" | "C" | "D" | "E" | "F"
+                         | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
+
+   Many HTTP/1.1 header field values consist of words separated by LWS
+   or special characters. These special characters MUST be in a quoted
+   string to be used within a parameter value.
+
+          token          = 1*<any CHAR except CTLs or tspecials>
+
+          tspecials      = "(" | ")" | "<" | ">" | "@"
+                         | "," | ";" | ":" | "\" | <">
+                         | "/" | "[" | "]" | "?" | "="
+                         | "{" | "}" | SP | HT
+
+   Comments can be included in some HTTP header fields by surrounding
+   the comment text with parentheses. Comments are only allowed in
+   fields containing "comment" as part of their field value definition.
+   In all other fields, parentheses are considered part of the field
+   value.
+
+          comment        = "(" *( ctext | comment ) ")"
+          ctext          = <any TEXT excluding "(" and ")">
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 16]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   A string of text is parsed as a single word if it is quoted using
+   double-quote marks.
+
+          quoted-string  = ( <"> *(qdtext) <"> )
+
+          qdtext         = <any TEXT except <">>
+
+   The backslash character ("\") may be used as a single-character quoting
+   mechanism only within quoted-string and comment constructs.
+
+          quoted-pair    = "\" CHAR
+
+3 Protocol Parameters
+
+3.1 HTTP Version
+
+   HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
+   of the protocol. The protocol versioning policy is intended to allow
+   the sender to indicate the format of a message and its capacity for
+   understanding further HTTP communication, rather than the features
+   obtained via that communication. No change is made to the version
+   number for the addition of message components which do not affect
+   communication behavior or which only add to extensible field values.
+   The <minor> number is incremented when the changes made to the
+   protocol add features which do not change the general message parsing
+   algorithm, but which may add to the message semantics and imply
+   additional capabilities of the sender. The <major> number is
+   incremented when the format of a message within the protocol is
+   changed.
+
+   The version of an HTTP message is indicated by an HTTP-Version field
+   in the first line of the message.
+
+          HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT
+
+   Note that the major and minor numbers MUST be treated as separate
+   integers and that each may be incremented higher than a single digit.
+   Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
+   lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
+   MUST NOT be sent.
+
+   Applications sending Request or Response messages, as defined by this
+   specification, MUST include an HTTP-Version of "HTTP/1.1". Use of
+   this version number indicates that the sending application is at
+   least conditionally compliant with this specification.
+
+   The HTTP version of an application is the highest HTTP version for
+   which the application is at least conditionally compliant.
+
+
+
+Fielding, et. al.           Standards Track                    [Page 17]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Proxy and gateway applications must be careful when forwarding
+   messages in protocol versions different from that of the application.
+   Since the protocol version indicates the protocol capability of the
+   sender, a proxy/gateway MUST never send a message with a version
+   indicator which is greater than its actual version; if a higher
+   version request is received, the proxy/gateway MUST either downgrade
+   the request version, respond with an error, or switch to tunnel
+   behavior. Requests with a version lower than that of the
+   proxy/gateway's version MAY be upgraded before being forwarded; the
+   proxy/gateway's response to that request MUST be in the same major
+   version as the request.
+
+     Note: Converting between versions of HTTP may involve modification
+     of header fields required or forbidden by the versions involved.
+
+3.2 Uniform Resource Identifiers
+
+   URIs have been known by many names: WWW addresses, Universal Document
+   Identifiers, Universal Resource Identifiers , and finally the
+   combination of Uniform Resource Locators (URL)  and Names (URN). As
+   far as HTTP is concerned, Uniform Resource Identifiers are simply
+   formatted strings which identify--via name, location, or any other
+   characteristic--a resource.
+
+3.2.1 General Syntax
+
+   URIs in HTTP can be represented in absolute form or relative to some
+   known base URI, depending upon the context of their use. The two
+   forms are differentiated by the fact that absolute URIs always begin
+   with a scheme name followed by a colon.
+
+          URI            = ( absoluteURI | relativeURI ) [ "#" fragment ]
+
+          absoluteURI    = scheme ":" *( uchar | reserved )
+
+          relativeURI    = net_path | abs_path | rel_path
+
+          net_path       = "//" net_loc [ abs_path ]
+          abs_path       = "/" rel_path
+          rel_path       = [ path ] [ ";" params ] [ "?" query ]
+
+          path           = fsegment *( "/" segment )
+          fsegment       = 1*pchar
+          segment        = *pchar
+
+          params         = param *( ";" param )
+          param          = *( pchar | "/" )
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 18]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+          scheme         = 1*( ALPHA | DIGIT | "+" | "-" | "." )
+          net_loc        = *( pchar | ";" | "?" )
+
+          query          = *( uchar | reserved )
+          fragment       = *( uchar | reserved )
+
+          pchar          = uchar | ":" | "@" | "&" | "=" | "+"
+          uchar          = unreserved | escape
+          unreserved     = ALPHA | DIGIT | safe | extra | national
+
+          escape         = "%" HEX HEX
+          reserved       = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
+          extra          = "!" | "*" | "'" | "(" | ")" | ","
+          safe           = "$" | "-" | "_" | "."
+          unsafe         = CTL | SP | <"> | "#" | "%" | "<" | ">"
+          national       = <any OCTET excluding ALPHA, DIGIT,
+                           reserved, extra, safe, and unsafe>
+
+   For definitive information on URL syntax and semantics, see RFC 1738
+   [4] and RFC 1808 [11]. The BNF above includes national characters not
+   allowed in valid URLs as specified by RFC 1738, since HTTP servers
+   are not restricted in the set of unreserved characters allowed to
+   represent the rel_path part of addresses, and HTTP proxies may
+   receive requests for URIs not defined by RFC 1738.
+
+   The HTTP protocol does not place any a priori limit on the length of
+   a URI. Servers MUST be able to handle the URI of any resource they
+   serve, and SHOULD be able to handle URIs of unbounded length if they
+   provide GET-based forms that could generate such URIs. A server
+   SHOULD return 414 (Request-URI Too Long) status if a URI is longer
+   than the server can handle (see section 10.4.15).
+
+     Note: Servers should be cautious about depending on URI lengths
+     above 255 bytes, because some older client or proxy implementations
+     may not properly support these lengths.
+
+3.2.2 http URL
+
+   The "http" scheme is used to locate network resources via the HTTP
+   protocol. This section defines the scheme-specific syntax and
+   semantics for http URLs.
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 19]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+          http_URL       = "http:" "//" host [ ":" port ] [ abs_path ]
+
+          host           = <A legal Internet host domain name
+                            or IP address (in dotted-decimal form),
+                            as defined by Section 2.1 of RFC 1123>
+
+          port           = *DIGIT
+
+   If the port is empty or not given, port 80 is assumed. The semantics
+   are that the identified resource is located at the server listening
+   for TCP connections on that port of that host, and the Request-URI
+   for the resource is abs_path. The use of IP addresses in URL's SHOULD
+   be avoided whenever possible (see RFC 1900 [24]). If the abs_path is
+   not present in the URL, it MUST be given as "/" when used as a
+   Request-URI for a resource (section 5.1.2).
+
+3.2.3 URI Comparison
+
+   When comparing two URIs to decide if they match or not, a client
+   SHOULD use a case-sensitive octet-by-octet comparison of the entire
+   URIs, with these exceptions:
+
+     o  A port that is empty or not given is equivalent to the default
+        port for that URI;
+
+     o  Comparisons of host names MUST be case-insensitive;
+
+     o  Comparisons of scheme names MUST be case-insensitive;
+
+     o  An empty abs_path is equivalent to an abs_path of "/".
+
+   Characters other than those in the "reserved" and "unsafe" sets (see
+   section 3.2) are equivalent to their ""%" HEX HEX" encodings.
+
+   For example, the following three URIs are equivalent:
+
+         http://abc.com:80/~smith/home.html
+         http://ABC.com/%7Esmith/home.html
+         http://ABC.com:/%7esmith/home.html
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 20]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+3.3 Date/Time Formats
+
+3.3.1 Full Date
+
+   HTTP applications have historically allowed three different formats
+   for the representation of date/time stamps:
+
+          Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
+          Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
+          Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
+
+   The first format is preferred as an Internet standard and represents
+   a fixed-length subset of that defined by RFC 1123  (an update to RFC
+   822).  The second format is in common use, but is based on the
+   obsolete RFC 850 [12] date format and lacks a four-digit year.
+   HTTP/1.1 clients and servers that parse the date value MUST accept
+   all three formats (for compatibility with HTTP/1.0), though they MUST
+   only generate the RFC 1123 format for representing HTTP-date values
+   in header fields.
+
+     Note: Recipients of date values are encouraged to be robust in
+     accepting date values that may have been sent by non-HTTP
+     applications, as is sometimes the case when retrieving or posting
+     messages via proxies/gateways to SMTP or NNTP.
+
+   All HTTP date/time stamps MUST be represented in Greenwich Mean Time
+   (GMT), without exception. This is indicated in the first two formats
+   by the inclusion of "GMT" as the three-letter abbreviation for time
+   zone, and MUST be assumed when reading the asctime format.
+
+          HTTP-date    = rfc1123-date | rfc850-date | asctime-date
+
+          rfc1123-date = wkday "," SP date1 SP time SP "GMT"
+          rfc850-date  = weekday "," SP date2 SP time SP "GMT"
+          asctime-date = wkday SP date3 SP time SP 4DIGIT
+
+          date1        = 2DIGIT SP month SP 4DIGIT
+                         ; day month year (e.g., 02 Jun 1982)
+          date2        = 2DIGIT "-" month "-" 2DIGIT
+                         ; day-month-year (e.g., 02-Jun-82)
+          date3        = month SP ( 2DIGIT | ( SP 1DIGIT ))
+                         ; month day (e.g., Jun  2)
+
+          time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
+                         ; 00:00:00 - 23:59:59
+
+          wkday        = "Mon" | "Tue" | "Wed"
+                       | "Thu" | "Fri" | "Sat" | "Sun"
+
+
+
+Fielding, et. al.           Standards Track                    [Page 21]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+          weekday      = "Monday" | "Tuesday" | "Wednesday"
+                       | "Thursday" | "Friday" | "Saturday" | "Sunday"
+
+          month        = "Jan" | "Feb" | "Mar" | "Apr"
+                       | "May" | "Jun" | "Jul" | "Aug"
+                       | "Sep" | "Oct" | "Nov" | "Dec"
+
+     Note: HTTP requirements for the date/time stamp format apply only
+     to their usage within the protocol stream. Clients and servers are
+     not required to use these formats for user presentation, request
+     logging, etc.
+
+3.3.2 Delta Seconds
+
+   Some HTTP header fields allow a time value to be specified as an
+   integer number of seconds, represented in decimal, after the time
+   that the message was received.
+
+          delta-seconds  = 1*DIGIT
+
+3.4 Character Sets
+
+   HTTP uses the same definition of the term "character set" as that
+   described for MIME:
+
+     The term "character set" is used in this document to refer to a
+     method used with one or more tables to convert a sequence of octets
+     into a sequence of characters. Note that unconditional conversion
+     in the other direction is not required, in that not all characters
+     may be available in a given character set and a character set may
+     provide more than one sequence of octets to represent a particular
+     character. This definition is intended to allow various kinds of
+     character encodings, from simple single-table mappings such as US-
+     ASCII to complex table switching methods such as those that use ISO
+     2022's techniques. However, the definition associated with a MIME
+     character set name MUST fully specify the mapping to be performed
+     from octets to characters. In particular, use of external profiling
+     information to determine the exact mapping is not permitted.
+
+     Note: This use of the term "character set" is more commonly
+     referred to as a "character encoding." However, since HTTP and MIME
+     share the same registry, it is important that the terminology also
+     be shared.
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 22]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   HTTP character sets are identified by case-insensitive tokens. The
+   complete set of tokens is defined by the IANA Character Set registry
+   [19].
+
+          charset = token
+
+   Although HTTP allows an arbitrary token to be used as a charset
+   value, any token that has a predefined value within the IANA
+   Character Set registry MUST represent the character set defined by
+   that registry.  Applications SHOULD limit their use of character sets
+   to those defined by the IANA registry.
+
+3.5 Content Codings
+
+   Content coding values indicate an encoding transformation that has
+   been or can be applied to an entity. Content codings are primarily
+   used to allow a document to be compressed or otherwise usefully
+   transformed without losing the identity of its underlying media type
+   and without loss of information. Frequently, the entity is stored in
+   coded form, transmitted directly, and only decoded by the recipient.
+
+          content-coding   = token
+
+   All content-coding values are case-insensitive. HTTP/1.1 uses
+   content-coding values in the Accept-Encoding (section 14.3) and
+   Content-Encoding (section 14.12) header fields. Although the value
+   describes the content-coding, what is more important is that it
+   indicates what decoding mechanism will be required to remove the
+   encoding.
+
+   The Internet Assigned Numbers Authority (IANA) acts as a registry for
+   content-coding value tokens. Initially, the registry contains the
+   following tokens:
+
+   gzip An encoding format produced by the file compression program "gzip"
+        (GNU zip) as described in RFC 1952 [25]. This format is a Lempel-
+        Ziv coding (LZ77) with a 32 bit CRC.
+
+   compress
+        The encoding format produced by the common UNIX file compression
+        program "compress". This format is an adaptive Lempel-Ziv-Welch
+        coding (LZW).
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 23]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+     Note: Use of program names for the identification of encoding
+     formats is not desirable and should be discouraged for future
+     encodings. Their use here is representative of historical practice,
+     not good design. For compatibility with previous implementations of
+     HTTP, applications should consider "x-gzip" and "x-compress" to be
+     equivalent to "gzip" and "compress" respectively.
+
+   deflate The "zlib" format defined in RFC 1950[31] in combination with
+        the "deflate" compression mechanism described in RFC 1951[29].
+
+   New content-coding value tokens should be registered; to allow
+   interoperability between clients and servers, specifications of the
+   content coding algorithms needed to implement a new value should be
+   publicly available and adequate for independent implementation, and
+   conform to the purpose of content coding defined in this section.
+
+3.6 Transfer Codings
+
+   Transfer coding values are used to indicate an encoding
+   transformation that has been, can be, or may need to be applied to an
+   entity-body in order to ensure "safe transport" through the network.
+   This differs from a content coding in that the transfer coding is a
+   property of the message, not of the original entity.
+
+          transfer-coding         = "chunked" | transfer-extension
+
+          transfer-extension      = token
+
+   All transfer-coding values are case-insensitive. HTTP/1.1 uses
+   transfer coding values in the Transfer-Encoding header field (section
+   14.40).
+
+   Transfer codings are analogous to the Content-Transfer-Encoding
+   values of MIME , which were designed to enable safe transport of
+   binary data over a 7-bit transport service. However, safe transport
+   has a different focus for an 8bit-clean transfer protocol. In HTTP,
+   the only unsafe characteristic of message-bodies is the difficulty in
+   determining the exact body length (section 7.2.2), or the desire to
+   encrypt data over a shared transport.
+
+   The chunked encoding modifies the body of a message in order to
+   transfer it as a series of chunks, each with its own size indicator,
+   followed by an optional footer containing entity-header fields. This
+   allows dynamically-produced content to be transferred along with the
+   information necessary for the recipient to verify that it has
+   received the full message.
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 24]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+       Chunked-Body   = *chunk
+                        "0" CRLF
+                        footer
+                        CRLF
+
+       chunk          = chunk-size [ chunk-ext ] CRLF
+                        chunk-data CRLF
+
+       hex-no-zero    = <HEX excluding "0">
+
+       chunk-size     = hex-no-zero *HEX
+       chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
+       chunk-ext-name = token
+       chunk-ext-val  = token | quoted-string
+       chunk-data     = chunk-size(OCTET)
+
+       footer         = *entity-header
+
+   The chunked encoding is ended by a zero-sized chunk followed by the
+   footer, which is terminated by an empty line. The purpose of the
+   footer is to provide an efficient way to supply information about an
+   entity that is generated dynamically; applications MUST NOT send
+   header fields in the footer which are not explicitly defined as being
+   appropriate for the footer, such as Content-MD5 or future extensions
+   to HTTP for digital signatures or other facilities.
+
+   An example process for decoding a Chunked-Body is presented in
+   appendix 19.4.6.
+
+   All HTTP/1.1 applications MUST be able to receive and decode the
+   "chunked" transfer coding, and MUST ignore transfer coding extensions
+   they do not understand. A server which receives an entity-body with a
+   transfer-coding it does not understand SHOULD return 501
+   (Unimplemented), and close the connection. A server MUST NOT send
+   transfer-codings to an HTTP/1.0 client.
+
+3.7 Media Types
+
+   HTTP uses Internet Media Types  in the Content-Type (section 14.18)
+   and Accept (section 14.1) header fields in order to provide open and
+   extensible data typing and type negotiation.
+
+          media-type     = type "/" subtype *( ";" parameter )
+          type           = token
+          subtype        = token
+
+   Parameters may follow the type/subtype in the form of attribute/value
+   pairs.
+
+
+
+Fielding, et. al.           Standards Track                    [Page 25]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+          parameter      = attribute "=" value
+          attribute      = token
+          value          = token | quoted-string
+
+   The type, subtype, and parameter attribute names are case-
+   insensitive.  Parameter values may or may not be case-sensitive,
+   depending on the semantics of the parameter name. Linear white space
+   (LWS) MUST NOT be used between the type and subtype, nor between an
+   attribute and its value. User agents that recognize the media-type
+   MUST process (or arrange to be processed by any external applications
+   used to process that type/subtype by the user agent) the parameters
+   for that MIME type as described by that type/subtype definition to
+   the and inform the user of any problems discovered.
+
+     Note: some older HTTP applications do not recognize media type
+     parameters. When sending data to older HTTP applications,
+     implementations should only use media type parameters when they are
+     required by that type/subtype definition.
+
+   Media-type values are registered with the Internet Assigned Number
+   Authority (IANA). The media type registration process is outlined in
+   RFC 2048 [17]. Use of non-registered media types is discouraged.
+
+3.7.1 Canonicalization and Text Defaults
+
+   Internet media types are registered with a canonical form. In
+   general, an entity-body transferred via HTTP messages MUST be
+   represented in the appropriate canonical form prior to its
+   transmission; the exception is "text" types, as defined in the next
+   paragraph.
+
+   When in canonical form, media subtypes of the "text" type use CRLF as
+   the text line break. HTTP relaxes this requirement and allows the
+   transport of text media with plain CR or LF alone representing a line
+   break when it is done consistently for an entire entity-body. HTTP
+   applications MUST accept CRLF, bare CR, and bare LF as being
+   representative of a line break in text media received via HTTP. In
+   addition, if the text is represented in a character set that does not
+   use octets 13 and 10 for CR and LF respectively, as is the case for
+   some multi-byte character sets, HTTP allows the use of whatever octet
+   sequences are defined by that character set to represent the
+   equivalent of CR and LF for line breaks. This flexibility regarding
+   line breaks applies only to text media in the entity-body; a bare CR
+   or LF MUST NOT be substituted for CRLF within any of the HTTP control
+   structures (such as header fields and multipart boundaries).
+
+   If an entity-body is encoded with a Content-Encoding, the underlying
+   data MUST be in a form defined above prior to being encoded.
+
+
+
+Fielding, et. al.           Standards Track                    [Page 26]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   The "charset" parameter is used with some media types to define the
+   character set (section 3.4) of the data. When no explicit charset
+   parameter is provided by the sender, media subtypes of the "text"
+   type are defined to have a default charset value of "ISO-8859-1" when
+   received via HTTP. Data in character sets other than "ISO-8859-1" or
+   its subsets MUST be labeled with an appropriate charset value.
+
+   Some HTTP/1.0 software has interpreted a Content-Type header without
+   charset parameter incorrectly to mean "recipient should guess."
+   Senders wishing to defeat this behavior MAY include a charset
+   parameter even when the charset is ISO-8859-1 and SHOULD do so when
+   it is known that it will not confuse the recipient.
+
+   Unfortunately, some older HTTP/1.0 clients did not deal properly with
+   an explicit charset parameter. HTTP/1.1 recipients MUST respect the
+   charset label provided by the sender; and those user agents that have
+   a provision to "guess" a charset MUST use the charset from the
+   content-type field if they support that charset, rather than the
+   recipient's preference, when initially displaying a document.
+
+3.7.2 Multipart Types
+
+   MIME provides for a number of "multipart" types -- encapsulations of
+   one or more entities within a single message-body. All multipart
+   types share a common syntax, as defined in  MIME [7], and MUST
+   include a boundary parameter as part of the media type value. The
+   message body is itself a protocol element and MUST therefore use only
+   CRLF to represent line breaks between body-parts. Unlike in MIME, the
+   epilogue of any multipart message MUST be empty; HTTP applications
+   MUST NOT transmit the epilogue (even if the original multipart
+   contains an epilogue).
+
+   In HTTP, multipart body-parts MAY contain header fields which are
+   significant to the meaning of that part. A Content-Location header
+   field (section 14.15) SHOULD be included in the body-part of each
+   enclosed entity that can be identified by a URL.
+
+   In general, an HTTP user agent SHOULD follow the same or similar
+   behavior as a MIME user agent would upon receipt of a multipart type.
+   If an application receives an unrecognized multipart subtype, the
+   application MUST treat it as being equivalent to "multipart/mixed".
+
+     Note: The "multipart/form-data" type has been specifically defined
+     for carrying form data suitable for processing via the POST request
+     method, as described in RFC 1867 [15].
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 27]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+3.8 Product Tokens
+
+   Product tokens are used to allow communicating applications to
+   identify themselves by software name and version. Most fields using
+   product tokens also allow sub-products which form a significant part
+   of the application to be listed, separated by whitespace. By
+   convention, the products are listed in order of their significance
+   for identifying the application.
+
+          product         = token ["/" product-version]
+          product-version = token
+
+   Examples:
+
+          User-Agent: CERN-LineMode/2.15 libwww/2.17b3
+          Server: Apache/0.8.4
+
+   Product tokens should be short and to the point -- use of them for
+   advertising or other non-essential information is explicitly
+   forbidden.  Although any token character may appear in a product-
+   version, this token SHOULD only be used for a version identifier
+   (i.e., successive versions of the same product SHOULD only differ in
+   the product-version portion of the product value).
+
+3.9 Quality Values
+
+   HTTP content negotiation (section 12) uses short "floating point"
+   numbers to indicate the relative importance ("weight") of various
+   negotiable parameters. A weight is normalized to a real number in the
+   range 0 through 1, where 0 is the minimum and 1 the maximum value.
+   HTTP/1.1 applications MUST NOT generate more than three digits after
+   the decimal point. User configuration of these values SHOULD also be
+   limited in this fashion.
+
+          qvalue         = ( "0" [ "." 0*3DIGIT ] )
+                         | ( "1" [ "." 0*3("0") ] )
+
+   "Quality values" is a misnomer, since these values merely represent
+   relative degradation in desired quality.
+
+3.10 Language Tags
+
+   A language tag identifies a natural language spoken, written, or
+   otherwise conveyed by human beings for communication of information
+   to other human beings. Computer languages are explicitly excluded.
+   HTTP uses language tags within the Accept-Language and Content-
+   Language fields.
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 28]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   The syntax and registry of HTTP language tags is the same as that
+   defined by RFC 1766 [1]. In summary, a language tag is composed of 1
+   or more parts: A primary language tag and a possibly empty series of
+   subtags:
+
+           language-tag  = primary-tag *( "-" subtag )
+
+           primary-tag   = 1*8ALPHA
+           subtag        = 1*8ALPHA
+
+   Whitespace is not allowed within the tag and all tags are case-
+   insensitive. The name space of language tags is administered by the
+   IANA. Example tags include:
+
+          en, en-US, en-cockney, i-cherokee, x-pig-latin
+
+   where any two-letter primary-tag is an ISO 639 language abbreviation
+   and any two-letter initial subtag is an ISO 3166 country code. (The
+   last three tags above are not registered tags; all but the last are
+   examples of tags which could be registered in future.)
+
+3.11 Entity Tags
+
+   Entity tags are used for comparing two or more entities from the same
+   requested resource. HTTP/1.1 uses entity tags in the ETag (section
+   14.20), If-Match (section 14.25), If-None-Match (section 14.26), and
+   If-Range (section 14.27) header fields. The definition of how they
+   are used and compared as cache validators is in section 13.3.3. An
+   entity tag consists of an opaque quoted string, possibly prefixed by
+   a weakness indicator.
+
+         entity-tag = [ weak ] opaque-tag
+
+         weak       = "W/"
+         opaque-tag = quoted-string
+
+   A "strong entity tag" may be shared by two entities of a resource
+   only if they are equivalent by octet equality.
+
+   A "weak entity tag," indicated by the "W/" prefix, may be shared by
+   two entities of a resource only if the entities are equivalent and
+   could be substituted for each other with no significant change in
+   semantics. A weak entity tag can only be used for weak comparison.
+
+   An entity tag MUST be unique across all versions of all entities
+   associated with a particular resource. A given entity tag value may
+   be used for entities obtained by requests on different URIs without
+   implying anything about the equivalence of those entities.
+
+
+
+Fielding, et. al.           Standards Track                    [Page 29]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+3.12 Range Units
+
+   HTTP/1.1 allows a client to request that only part (a range of) the
+   response entity be included within the response. HTTP/1.1 uses range
+   units in the Range (section 14.36) and Content-Range (section 14.17)
+   header fields. An entity may be broken down into subranges according
+   to various structural units.
+
+         range-unit       = bytes-unit | other-range-unit
+
+         bytes-unit       = "bytes"
+         other-range-unit = token
+
+The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
+   implementations may ignore ranges specified using other units.
+   HTTP/1.1 has been designed to allow implementations of applications
+   that do not depend on knowledge of ranges.
+
+4 HTTP Message
+
+4.1 Message Types
+
+   HTTP messages consist of requests from client to server and responses
+   from server to client.
+
+          HTTP-message   = Request | Response     ; HTTP/1.1 messages
+
+   Request (section 5) and Response (section 6) messages use the generic
+   message format of RFC 822 [9] for transferring entities (the payload
+   of the message). Both types of message consist of a start-line, one
+   or more header fields (also known as "headers"), an empty line (i.e.,
+   a line with nothing preceding the CRLF) indicating the end of the
+   header fields, and an optional message-body.
+
+           generic-message = start-line
+                             *message-header
+                             CRLF
+                             [ message-body ]
+
+           start-line      = Request-Line | Status-Line
+
+   In the interest of robustness, servers SHOULD ignore any empty
+   line(s) received where a Request-Line is expected. In other words, if
+   the server is reading the protocol stream at the beginning of a
+   message and receives a CRLF first, it should ignore the CRLF.
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 30]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+     Note: certain buggy HTTP/1.0 client implementations generate an
+     extra CRLF's after a POST request. To restate what is explicitly
+     forbidden by the BNF, an HTTP/1.1 client must not preface or follow
+     a request with an extra CRLF.
+
+4.2 Message Headers
+
+   HTTP header fields, which include general-header (section 4.5),
+   request-header (section 5.3), response-header (section 6.2), and
+   entity-header (section 7.1) fields, follow the same generic format as
+   that given in Section 3.1 of RFC 822 [9]. Each header field consists
+   of a name followed by a colon (":") and the field value. Field names
+   are case-insensitive. The field value may be preceded by any amount
+   of LWS, though a single SP is preferred. Header fields can be
+   extended over multiple lines by preceding each extra line with at
+   least one SP or HT.  Applications SHOULD follow "common form" when
+   generating HTTP constructs, since there might exist some
+   implementations that fail to accept anything beyond the common forms.
+
+          message-header = field-name ":" [ field-value ] CRLF
+
+          field-name     = token
+          field-value    = *( field-content | LWS )
+
+          field-content  = <the OCTETs making up the field-value
+                           and consisting of either *TEXT or combinations
+                           of token, tspecials, and quoted-string>
+
+   The order in which header fields with differing field names are
+   received is not significant. However, it is "good practice" to send
+   general-header fields first, followed by request-header or response-
+   header fields, and ending with the entity-header fields.
+
+   Multiple message-header fields with the same field-name may be
+   present in a message if and only if the entire field-value for that
+   header field is defined as a comma-separated list [i.e., #(values)].
+   It MUST be possible to combine the multiple header fields into one
+   "field-name: field-value" pair, without changing the semantics of the
+   message, by appending each subsequent field-value to the first, each
+   separated by a comma. The order in which header fields with the same
+   field-name are received is therefore significant to the
+   interpretation of the combined field value, and thus a proxy MUST NOT
+   change the order of these field values when a message is forwarded.
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 31]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+4.3 Message Body
+
+   The message-body (if any) of an HTTP message is used to carry the
+   entity-body associated with the request or response. The message-body
+   differs from the entity-body only when a transfer coding has been
+   applied, as indicated by the Transfer-Encoding header field (section
+   14.40).
+
+          message-body = entity-body
+                       | <entity-body encoded as per Transfer-Encoding>
+
+   Transfer-Encoding MUST be used to indicate any transfer codings
+   applied by an application to ensure safe and proper transfer of the
+   message.  Transfer-Encoding is a property of the message, not of the
+   entity, and thus can be added or removed by any application along the
+   request/response chain.
+
+   The rules for when a message-body is allowed in a message differ for
+   requests and responses.
+
+   The presence of a message-body in a request is signaled by the
+   inclusion of a Content-Length or Transfer-Encoding header field in
+   the request's message-headers. A message-body MAY be included in a
+   request only when the request method (section 5.1.1) allows an
+   entity-body.
+
+   For response messages, whether or not a message-body is included with
+   a message is dependent on both the request method and the response
+   status code (section 6.1.1). All responses to the HEAD request method
+   MUST NOT include a message-body, even though the presence of entity-
+   header fields might lead one to believe they do. All 1xx
+   (informational), 204 (no content), and 304 (not modified) responses
+   MUST NOT include a message-body. All other responses do include a
+   message-body, although it may be of zero length.
+
+4.4 Message Length
+
+   When a message-body is included with a message, the length of that
+   body is determined by one of the following (in order of precedence):
+
+   1. Any response message which MUST NOT include a message-body
+     (such as the 1xx, 204, and 304 responses and any response to a HEAD
+     request) is always terminated by the first empty line after the
+     header fields, regardless of the entity-header fields present in the
+     message.
+
+   2. If a Transfer-Encoding header field (section 14.40) is present and
+     indicates that the "chunked" transfer coding has been applied, then
+
+
+
+Fielding, et. al.           Standards Track                    [Page 32]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+     the length is defined by the chunked encoding (section 3.6).
+
+   3. If a Content-Length header field (section 14.14) is present, its
+     value in bytes represents the length of the message-body.
+
+   4. If the message uses the media type "multipart/byteranges", which is
+     self-delimiting, then that defines the length. This media type MUST
+     NOT be used unless the sender knows that the recipient can parse it;
+     the presence in a request of a Range header with multiple byte-range
+     specifiers implies that the client can parse multipart/byteranges
+     responses.
+
+   5. By the server closing the connection. (Closing the connection
+     cannot be used to indicate the end of a request body, since that
+     would leave no possibility for the server to send back a response.)
+
+   For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
+   containing a message-body MUST include a valid Content-Length header
+   field unless the server is known to be HTTP/1.1 compliant. If a
+   request contains a message-body and a Content-Length is not given,
+   the server SHOULD respond with 400 (bad request) if it cannot
+   determine the length of the message, or with 411 (length required) if
+   it wishes to insist on receiving a valid Content-Length.
+
+   All HTTP/1.1 applications that receive entities MUST accept the
+   "chunked" transfer coding (section 3.6), thus allowing this mechanism
+   to be used for messages when the message length cannot be determined
+   in advance.
+
+   Messages MUST NOT include both a Content-Length header field and the
+   "chunked" transfer coding. If both are received, the Content-Length
+   MUST be ignored.
+
+   When a Content-Length is given in a message where a message-body is
+   allowed, its field value MUST exactly match the number of OCTETs in
+   the message-body. HTTP/1.1 user agents MUST notify the user when an
+   invalid length is received and detected.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 33]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+4.5 General Header Fields
+
+   There are a few header fields which have general applicability for
+   both request and response messages, but which do not apply to the
+   entity being transferred. These header fields apply only to the
+   message being transmitted.
+
+          general-header = Cache-Control            ; Section 14.9
+                         | Connection               ; Section 14.10
+                         | Date                     ; Section 14.19
+                         | Pragma                   ; Section 14.32
+                         | Transfer-Encoding        ; Section 14.40
+                         | Upgrade                  ; Section 14.41
+                         | Via                      ; Section 14.44
+
+   General-header field names can be extended reliably only in
+   combination with a change in the protocol version. However, new or
+   experimental header fields may be given the semantics of general
+   header fields if all parties in the communication recognize them to
+   be general-header fields.  Unrecognized header fields are treated as
+   entity-header fields.
+
+5 Request
+
+   A request message from a client to a server includes, within the
+   first line of that message, the method to be applied to the resource,
+   the identifier of the resource, and the protocol version in use.
+
+           Request       = Request-Line              ; Section 5.1
+                           *( general-header         ; Section 4.5
+                            | request-header         ; Section 5.3
+                            | entity-header )        ; Section 7.1
+                           CRLF
+                           [ message-body ]          ; Section 7.2
+
+5.1 Request-Line
+
+   The Request-Line begins with a method token, followed by the
+   Request-URI and the protocol version, and ending with CRLF. The
+   elements are separated by SP characters. No CR or LF are allowed
+   except in the final CRLF sequence.
+
+          Request-Line   = Method SP Request-URI SP HTTP-Version CRLF
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 34]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+5.1.1 Method
+
+   The Method token indicates the method to be performed on the resource
+   identified by the Request-URI. The method is case-sensitive.
+
+          Method         = "OPTIONS"                ; Section 9.2
+                         | "GET"                    ; Section 9.3
+                         | "HEAD"                   ; Section 9.4
+                         | "POST"                   ; Section 9.5
+                         | "PUT"                    ; Section 9.6
+                         | "DELETE"                 ; Section 9.7
+                         | "TRACE"                  ; Section 9.8
+                         | extension-method
+
+          extension-method = token
+
+   The list of methods allowed by a resource can be specified in an
+   Allow header field (section 14.7). The return code of the response
+   always notifies the client whether a method is currently allowed on a
+   resource, since the set of allowed methods can change dynamically.
+   Servers SHOULD return the status code 405 (Method Not Allowed) if the
+   method is known by the server but not allowed for the requested
+   resource, and 501 (Not Implemented) if the method is unrecognized or
+   not implemented by the server. The list of methods known by a server
+   can be listed in a Public response-header field (section 14.35).
+
+   The methods GET and HEAD MUST be supported by all general-purpose
+   servers. All other methods are optional; however, if the above
+   methods are implemented, they MUST be implemented with the same
+   semantics as those specified in section 9.
+
+5.1.2 Request-URI
+
+   The Request-URI is a Uniform Resource Identifier (section 3.2) and
+   identifies the resource upon which to apply the request.
+
+          Request-URI    = "*" | absoluteURI | abs_path
+
+   The three options for Request-URI are dependent on the nature of the
+   request. The asterisk "*" means that the request does not apply to a
+   particular resource, but to the server itself, and is only allowed
+   when the method used does not necessarily apply to a resource. One
+   example would be
+
+          OPTIONS * HTTP/1.1
+
+   The absoluteURI form is required when the request is being made to a
+   proxy. The proxy is requested to forward the request or service it
+
+
+
+Fielding, et. al.           Standards Track                    [Page 35]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   from a valid cache, and return the response. Note that the proxy MAY
+   forward the request on to another proxy or directly to the server
+   specified by the absoluteURI. In order to avoid request loops, a
+   proxy MUST be able to recognize all of its server names, including
+   any aliases, local variations, and the numeric IP address. An example
+   Request-Line would be:
+
+          GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
+
+   To allow for transition to absoluteURIs in all requests in future
+   versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
+   form in requests, even though HTTP/1.1 clients will only generate
+   them in requests to proxies.
+
+   The most common form of Request-URI is that used to identify a
+   resource on an origin server or gateway. In this case the absolute
+   path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
+   the Request-URI, and the network location of the URI (net_loc) MUST
+   be transmitted in a Host header field. For example, a client wishing
+   to retrieve the resource above directly from the origin server would
+   create a TCP connection to port 80 of the host "www.w3.org" and send
+   the lines:
+
+          GET /pub/WWW/TheProject.html HTTP/1.1
+          Host: www.w3.org
+
+   followed by the remainder of the Request. Note that the absolute path
+   cannot be empty; if none is present in the original URI, it MUST be
+   given as "/" (the server root).
+
+   If a proxy receives a request without any path in the Request-URI and
+   the method specified is capable of supporting the asterisk form of
+   request, then the last proxy on the request chain MUST forward the
+   request with "*" as the final Request-URI. For example, the request
+
+          OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1
+
+   would be forwarded by the proxy as
+
+          OPTIONS * HTTP/1.1
+          Host: www.ics.uci.edu:8001
+
+   after connecting to port 8001 of host "www.ics.uci.edu".
+
+   The Request-URI is transmitted in the format specified in section
+   3.2.1.  The origin server MUST decode the Request-URI in order to
+   properly interpret the request. Servers SHOULD respond to invalid
+   Request-URIs with an appropriate status code.
+
+
+
+Fielding, et. al.           Standards Track                    [Page 36]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   In requests that they forward, proxies MUST NOT rewrite the
+   "abs_path" part of a Request-URI in any way except as noted above to
+   replace a null abs_path with "*", no matter what the proxy does in
+   its internal implementation.
+
+     Note: The "no rewrite" rule prevents the proxy from changing the
+     meaning of the request when the origin server is improperly using a
+     non-reserved URL character for a reserved purpose. Implementers
+     should be aware that some pre-HTTP/1.1 proxies have been known to
+     rewrite the Request-URI.
+
+5.2 The Resource Identified by a Request
+
+   HTTP/1.1 origin servers SHOULD be aware that the exact resource
+   identified by an Internet request is determined by examining both the
+   Request-URI and the Host header field.
+
+   An origin server that does not allow resources to differ by the
+   requested host MAY ignore the Host header field value. (But see
+   section 19.5.1 for other requirements on Host support in HTTP/1.1.)
+
+   An origin server that does differentiate resources based on the host
+   requested (sometimes referred to as virtual hosts or vanity
+   hostnames) MUST use the following rules for determining the requested
+   resource on an HTTP/1.1 request:
+
+     1. If Request-URI is an absoluteURI, the host is part of the
+        Request-URI. Any Host header field value in the request MUST be
+        ignored.
+
+     2. If the Request-URI is not an absoluteURI, and the request
+        includes a Host header field, the host is determined by the Host
+        header field value.
+
+     3. If the host as determined by rule 1 or 2 is not a valid host on
+        the server, the response MUST be a 400 (Bad Request) error
+        message.
+
+   Recipients of an HTTP/1.0 request that lacks a Host header field MAY
+   attempt to use heuristics (e.g., examination of the URI path for
+   something unique to a particular host) in order to determine what
+   exact resource is being requested.
+
+5.3 Request Header Fields
+
+   The request-header fields allow the client to pass additional
+   information about the request, and about the client itself, to the
+   server. These fields act as request modifiers, with semantics
+
+
+
+Fielding, et. al.           Standards Track                    [Page 37]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   equivalent to the parameters on a programming language method
+   invocation.
+
+          request-header = Accept                   ; Section 14.1
+                         | Accept-Charset           ; Section 14.2
+                         | Accept-Encoding          ; Section 14.3
+                         | Accept-Language          ; Section 14.4
+                         | Authorization            ; Section 14.8
+                         | From                     ; Section 14.22
+                         | Host                     ; Section 14.23
+                         | If-Modified-Since        ; Section 14.24
+                         | If-Match                 ; Section 14.25
+                         | If-None-Match            ; Section 14.26
+                         | If-Range                 ; Section 14.27
+                         | If-Unmodified-Since      ; Section 14.28
+                         | Max-Forwards             ; Section 14.31
+                         | Proxy-Authorization      ; Section 14.34
+                         | Range                    ; Section 14.36
+                         | Referer                  ; Section 14.37
+                         | User-Agent               ; Section 14.42
+
+   Request-header field names can be extended reliably only in
+   combination with a change in the protocol version. However, new or
+   experimental header fields MAY be given the semantics of request-
+   header fields if all parties in the communication recognize them to
+   be request-header fields.  Unrecognized header fields are treated as
+   entity-header fields.
+
+6 Response
+
+   After receiving and interpreting a request message, a server responds
+   with an HTTP response message.
+
+       Response      = Status-Line               ; Section 6.1
+                       *( general-header         ; Section 4.5
+                        | response-header        ; Section 6.2
+                        | entity-header )        ; Section 7.1
+                       CRLF
+                       [ message-body ]          ; Section 7.2
+
+6.1 Status-Line
+
+   The first line of a Response message is the Status-Line, consisting
+   of the protocol version followed by a numeric status code and its
+   associated textual phrase, with each element separated by SP
+   characters.  No CR or LF is allowed except in the final CRLF
+   sequence.
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 38]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+       Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
+
+6.1.1 Status Code and Reason Phrase
+
+   The Status-Code element is a 3-digit integer result code of the
+   attempt to understand and satisfy the request. These codes are fully
+   defined in section 10. The Reason-Phrase is intended to give a short
+   textual description of the Status-Code. The Status-Code is intended
+   for use by automata and the Reason-Phrase is intended for the human
+   user. The client is not required to examine or display the Reason-
+   Phrase.
+
+   The first digit of the Status-Code defines the class of response. The
+   last two digits do not have any categorization role. There are 5
+   values for the first digit:
+
+     o  1xx: Informational - Request received, continuing process
+
+     o  2xx: Success - The action was successfully received, understood,
+        and accepted
+
+     o  3xx: Redirection - Further action must be taken in order to
+        complete the request
+
+     o  4xx: Client Error - The request contains bad syntax or cannot be
+        fulfilled
+
+     o  5xx: Server Error - The server failed to fulfill an apparently
+        valid request
+
+   The individual values of the numeric status codes defined for
+   HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
+   presented below. The reason phrases listed here are only recommended
+   -- they may be replaced by local equivalents without affecting the
+   protocol.
+
+          Status-Code    = "100"   ; Continue
+                         | "101"   ; Switching Protocols
+                         | "200"   ; OK
+                         | "201"   ; Created
+                         | "202"   ; Accepted
+                         | "203"   ; Non-Authoritative Information
+                         | "204"   ; No Content
+                         | "205"   ; Reset Content
+                         | "206"   ; Partial Content
+                         | "300"   ; Multiple Choices
+                         | "301"   ; Moved Permanently
+                         | "302"   ; Moved Temporarily
+
+
+
+Fielding, et. al.           Standards Track                    [Page 39]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+                         | "303"   ; See Other
+                         | "304"   ; Not Modified
+                         | "305"   ; Use Proxy
+                         | "400"   ; Bad Request
+                         | "401"   ; Unauthorized
+                         | "402"   ; Payment Required
+                         | "403"   ; Forbidden
+                         | "404"   ; Not Found
+                         | "405"   ; Method Not Allowed
+                         | "406"   ; Not Acceptable
+                         | "407"   ; Proxy Authentication Required
+                         | "408"   ; Request Time-out
+                         | "409"   ; Conflict
+                         | "410"   ; Gone
+                         | "411"   ; Length Required
+                         | "412"   ; Precondition Failed
+                         | "413"   ; Request Entity Too Large
+                         | "414"   ; Request-URI Too Large
+                         | "415"   ; Unsupported Media Type
+                         | "500"   ; Internal Server Error
+                         | "501"   ; Not Implemented
+                         | "502"   ; Bad Gateway
+                         | "503"   ; Service Unavailable
+                         | "504"   ; Gateway Time-out
+                         | "505"   ; HTTP Version not supported
+                         | extension-code
+
+          extension-code = 3DIGIT
+
+          Reason-Phrase  = *<TEXT, excluding CR, LF>
+
+   HTTP status codes are extensible. HTTP applications are not required
+   to understand the meaning of all registered status codes, though such
+   understanding is obviously desirable. However, applications MUST
+   understand the class of any status code, as indicated by the first
+   digit, and treat any unrecognized response as being equivalent to the
+   x00 status code of that class, with the exception that an
+   unrecognized response MUST NOT be cached. For example, if an
+   unrecognized status code of 431 is received by the client, it can
+   safely assume that there was something wrong with its request and
+   treat the response as if it had received a 400 status code. In such
+   cases, user agents SHOULD present to the user the entity returned
+   with the response, since that entity is likely to include human-
+   readable information which will explain the unusual status.
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 40]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+6.2 Response Header Fields
+
+   The response-header fields allow the server to pass additional
+   information about the response which cannot be placed in the Status-
+   Line. These header fields give information about the server and about
+   further access to the resource identified by the Request-URI.
+
+          response-header = Age                     ; Section 14.6
+                          | Location                ; Section 14.30
+                          | Proxy-Authenticate      ; Section 14.33
+                          | Public                  ; Section 14.35
+                          | Retry-After             ; Section 14.38
+                          | Server                  ; Section 14.39
+                          | Vary                    ; Section 14.43
+                          | Warning                 ; Section 14.45
+                          | WWW-Authenticate        ; Section 14.46
+
+   Response-header field names can be extended reliably only in
+   combination with a change in the protocol version. However, new or
+   experimental header fields MAY be given the semantics of response-
+   header fields if all parties in the communication recognize them to
+   be response-header fields. Unrecognized header fields are treated as
+   entity-header fields.
+
+7 Entity
+
+   Request and Response messages MAY transfer an entity if not otherwise
+   restricted by the request method or response status code. An entity
+   consists of entity-header fields and an entity-body, although some
+   responses will only include the entity-headers.
+
+   In this section, both sender and recipient refer to either the client
+   or the server, depending on who sends and who receives the entity.
+
+7.1 Entity Header Fields
+
+   Entity-header fields define optional metainformation about the
+   entity-body or, if no body is present, about the resource identified
+   by the request.
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 41]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+          entity-header  = Allow                    ; Section 14.7
+                         | Content-Base             ; Section 14.11
+                         | Content-Encoding         ; Section 14.12
+                         | Content-Language         ; Section 14.13
+                         | Content-Length           ; Section 14.14
+                         | Content-Location         ; Section 14.15
+                         | Content-MD5              ; Section 14.16
+                         | Content-Range            ; Section 14.17
+                         | Content-Type             ; Section 14.18
+                         | ETag                     ; Section 14.20
+                         | Expires                  ; Section 14.21
+                         | Last-Modified            ; Section 14.29
+                         | extension-header
+
+          extension-header = message-header
+
+   The extension-header mechanism allows additional entity-header fields
+   to be defined without changing the protocol, but these fields cannot
+   be assumed to be recognizable by the recipient. Unrecognized header
+   fields SHOULD be ignored by the recipient and forwarded by proxies.
+
+7.2 Entity Body
+
+   The entity-body (if any) sent with an HTTP request or response is in
+   a format and encoding defined by the entity-header fields.
+
+          entity-body    = *OCTET
+
+   An entity-body is only present in a message when a message-body is
+   present, as described in section 4.3. The entity-body is obtained
+   from the message-body by decoding any Transfer-Encoding that may have
+   been applied to ensure safe and proper transfer of the message.
+
+7.2.1 Type
+
+   When an entity-body is included with a message, the data type of that
+   body is determined via the header fields Content-Type and Content-
+   Encoding. These define a two-layer, ordered encoding model:
+
+          entity-body := Content-Encoding( Content-Type( data ) )
+
+   Content-Type specifies the media type of the underlying data.
+   Content-Encoding may be used to indicate any additional content
+   codings applied to the data, usually for the purpose of data
+   compression, that are a property of the requested resource. There is
+   no default encoding.
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 42]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Any HTTP/1.1 message containing an entity-body SHOULD include a
+   Content-Type header field defining the media type of that body. If
+   and only if the media type is not given by a Content-Type field, the
+   recipient MAY attempt to guess the media type via inspection of its
+   content and/or the name extension(s) of the URL used to identify the
+   resource. If the media type remains unknown, the recipient SHOULD
+   treat it as type "application/octet-stream".
+
+7.2.2 Length
+
+   The length of an entity-body is the length of the message-body after
+   any transfer codings have been removed. Section 4.4 defines how the
+   length of a message-body is determined.
+
+8 Connections
+
+8.1 Persistent Connections
+
+8.1.1 Purpose
+
+   Prior to persistent connections, a separate TCP connection was
+   established to fetch each URL, increasing the load on HTTP servers
+   and causing congestion on the Internet. The use of inline images and
+   other associated data often requires a client to make multiple
+   requests of the same server in a short amount of time. Analyses of
+   these performance problems are available [30][27]; analysis and
+   results from a prototype implementation are in [26].
+
+   Persistent HTTP connections have a number of advantages:
+
+     o  By opening and closing fewer TCP connections, CPU time is saved,
+        and memory used for TCP protocol control blocks is also saved.
+     o  HTTP requests and responses can be pipelined on a connection.
+        Pipelining allows a client to make multiple requests without
+        waiting for each response, allowing a single TCP connection to be
+        used much more efficiently, with much lower elapsed time.
+     o  Network congestion is reduced by reducing the number of packets
+        caused by TCP opens, and by allowing TCP sufficient time to
+        determine the congestion state of the network.
+     o  HTTP can evolve more gracefully; since errors can be reported
+        without the penalty of closing the TCP connection. Clients using
+        future versions of HTTP might optimistically try a new feature, but
+        if communicating with an older server, retry with old semantics
+        after an error is reported.
+
+   HTTP implementations SHOULD implement persistent connections.
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 43]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+8.1.2 Overall Operation
+
+   A significant difference between HTTP/1.1 and earlier versions of
+   HTTP is that persistent connections are the default behavior of any
+   HTTP connection. That is, unless otherwise indicated, the client may
+   assume that the server will maintain a persistent connection.
+
+   Persistent connections provide a mechanism by which a client and a
+   server can signal the close of a TCP connection. This signaling takes
+   place using the Connection header field. Once a close has been
+   signaled, the client MUST not send any more requests on that
+   connection.
+
+8.1.2.1 Negotiation
+
+   An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
+   maintain a persistent connection unless a Connection header including
+   the connection-token "close" was sent in the request. If the server
+   chooses to close the connection immediately after sending the
+   response, it SHOULD send a Connection header including the
+   connection-token close.
+
+   An HTTP/1.1 client MAY expect a connection to remain open, but would
+   decide to keep it open based on whether the response from a server
+   contains a Connection header with the connection-token close. In case
+   the client does not want to maintain a connection for more than that
+   request, it SHOULD send a Connection header including the
+   connection-token close.
+
+   If either the client or the server sends the close token in the
+   Connection header, that request becomes the last one for the
+   connection.
+
+   Clients and servers SHOULD NOT assume that a persistent connection is
+   maintained for HTTP versions less than 1.1 unless it is explicitly
+   signaled. See section 19.7.1 for more information on backwards
+   compatibility with HTTP/1.0 clients.
+
+   In order to remain persistent, all messages on the connection must
+   have a self-defined message length (i.e., one not defined by closure
+   of the connection), as described in section 4.4.
+
+8.1.2.2 Pipelining
+
+   A client that supports persistent connections MAY "pipeline" its
+   requests (i.e., send multiple requests without waiting for each
+   response). A server MUST send its responses to those requests in the
+   same order that the requests were received.
+
+
+
+Fielding, et. al.           Standards Track                    [Page 44]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Clients which assume persistent connections and pipeline immediately
+   after connection establishment SHOULD be prepared to retry their
+   connection if the first pipelined attempt fails. If a client does
+   such a retry, it MUST NOT pipeline before it knows the connection is
+   persistent. Clients MUST also be prepared to resend their requests if
+   the server closes the connection before sending all of the
+   corresponding responses.
+
+8.1.3 Proxy Servers
+
+   It is especially important that proxies correctly implement the
+   properties of the Connection header field as specified in 14.2.1.
+
+   The proxy server MUST signal persistent connections separately with
+   its clients and the origin servers (or other proxy servers) that it
+   connects to. Each persistent connection applies to only one transport
+   link.
+
+   A proxy server MUST NOT establish a persistent connection with an
+   HTTP/1.0 client.
+
+8.1.4 Practical Considerations
+
+   Servers will usually have some time-out value beyond which they will
+   no longer maintain an inactive connection. Proxy servers might make
+   this a higher value since it is likely that the client will be making
+   more connections through the same server. The use of persistent
+   connections places no requirements on the length of this time-out for
+   either the client or the server.
+
+   When a client or server wishes to time-out it SHOULD issue a graceful
+   close on the transport connection. Clients and servers SHOULD both
+   constantly watch for the other side of the transport close, and
+   respond to it as appropriate. If a client or server does not detect
+   the other side's close promptly it could cause unnecessary resource
+   drain on the network.
+
+   A client, server, or proxy MAY close the transport connection at any
+   time. For example, a client MAY have started to send a new request at
+   the same time that the server has decided to close the "idle"
+   connection. From the server's point of view, the connection is being
+   closed while it was idle, but from the client's point of view, a
+   request is in progress.
+
+   This means that clients, servers, and proxies MUST be able to recover
+   from asynchronous close events. Client software SHOULD reopen the
+   transport connection and retransmit the aborted request without user
+   interaction so long as the request method is idempotent (see section
+
+
+
+Fielding, et. al.           Standards Track                    [Page 45]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   9.1.2); other methods MUST NOT be automatically retried, although
+   user agents MAY offer a human operator the choice of retrying the
+   request.
+
+   However, this automatic retry SHOULD NOT be repeated if the second
+   request fails.
+
+   Servers SHOULD always respond to at least one request per connection,
+   if at all possible. Servers SHOULD NOT close a connection in the
+   middle of transmitting a response, unless a network or client failure
+   is suspected.
+
+   Clients that use persistent connections SHOULD limit the number of
+   simultaneous connections that they maintain to a given server. A
+   single-user client SHOULD maintain AT MOST 2 connections with any
+   server or proxy. A proxy SHOULD use up to 2*N connections to another
+   server or proxy, where N is the number of simultaneously active
+   users. These guidelines are intended to improve HTTP response times
+   and avoid congestion of the Internet or other networks.
+
+8.2 Message Transmission Requirements
+
+General requirements:
+
+o  HTTP/1.1 servers SHOULD maintain persistent connections and use
+   TCP's flow control mechanisms to resolve temporary overloads,
+   rather than terminating connections with the expectation that
+   clients will retry. The latter technique can exacerbate network
+   congestion.
+
+o  An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
+   the network connection for an error status while it is transmitting
+   the request. If the client sees an error status, it SHOULD
+   immediately cease transmitting the body. If the body is being sent
+   using a "chunked" encoding (section 3.6), a zero length chunk and
+   empty footer MAY be used to prematurely mark the end of the
+   message. If the body was preceded by a Content-Length header, the
+   client MUST close the connection.
+
+o  An HTTP/1.1 (or later) client MUST be prepared to accept a 100
+   (Continue) status followed by a regular response.
+
+o  An HTTP/1.1 (or later) server that receives a request from a
+   HTTP/1.0 (or earlier) client MUST NOT transmit the 100 (continue)
+   response; it SHOULD either wait for the request to be completed
+   normally (thus avoiding an interrupted request) or close the
+   connection prematurely.
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 46]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Upon receiving a method subject to these requirements from an
+   HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either
+   respond with 100 (Continue) status and continue to read from the
+   input stream, or respond with an error status. If it responds with an
+   error status, it MAY close the transport (TCP) connection or it MAY
+   continue to read and discard the rest of the request. It MUST NOT
+   perform the requested method if it returns an error status.
+
+   Clients SHOULD remember the version number of at least the most
+   recently used server; if an HTTP/1.1 client has seen an HTTP/1.1 or
+   later response from the server, and it sees the connection close
+   before receiving any status from the server, the client SHOULD retry
+   the request without user interaction so long as the request method is
+   idempotent (see section 9.1.2); other methods MUST NOT be
+   automatically retried, although user agents MAY offer a human
+   operator the choice of retrying the request.. If the client does
+   retry the request, the client
+
+     o  MUST first send the request header fields, and then
+
+     o  MUST wait for the server to respond with either a 100 (Continue)
+        response, in which case the client should continue, or with an
+        error status.
+
+   If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from
+   the server, it should assume that the server implements HTTP/1.0 or
+   older and will not use the 100 (Continue) response. If in this case
+   the client sees the connection close before receiving any status from
+   the server, the client SHOULD retry the request. If the client does
+   retry the request to this HTTP/1.0 server, it should use the
+   following "binary exponential backoff" algorithm to be assured of
+   obtaining a reliable response:
+
+  1. Initiate a new connection to the server
+
+  2. Transmit the request-headers
+
+  3. Initialize a variable R to the estimated round-trip time to the
+     server (e.g., based on the time it took to establish the
+     connection), or to a constant value of 5 seconds if the round-trip
+     time is not available.
+
+  4. Compute T = R * (2**N), where N is the number of previous retries
+     of this request.
+
+  5. Wait either for an error response from the server, or for T seconds
+     (whichever comes first)
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 47]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+  6. If no error response is received, after T seconds transmit the body
+     of the request.
+
+  7. If client sees that the connection is closed prematurely, repeat
+     from step 1 until the request is accepted, an error response is
+     received, or the user becomes impatient and terminates the retry
+     process.
+
+   No matter what the server version, if an error status is received,
+   the client
+
+  o  MUST NOT continue and
+
+  o  MUST close the connection if it has not completed sending the
+     message.
+
+   An HTTP/1.1 (or later) client that sees the connection close after
+   receiving a 100 (Continue) but before receiving any other status
+   SHOULD retry the request, and need not wait for 100 (Continue)
+   response (but MAY do so if this simplifies the implementation).
+
+9 Method Definitions
+
+   The set of common methods for HTTP/1.1 is defined below. Although
+   this set can be expanded, additional methods cannot be assumed to
+   share the same semantics for separately extended clients and servers.
+
+   The Host request-header field (section 14.23) MUST accompany all
+   HTTP/1.1 requests.
+
+9.1 Safe and Idempotent Methods
+
+9.1.1 Safe Methods
+
+   Implementers should be aware that the software represents the user in
+   their interactions over the Internet, and should be careful to allow
+   the user to be aware of any actions they may take which may have an
+   unexpected significance to themselves or others.
+
+   In particular, the convention has been established that the GET and
+   HEAD methods should never have the significance of taking an action
+   other than retrieval. These methods should be considered "safe." This
+   allows user agents to represent other methods, such as POST, PUT and
+   DELETE, in a special way, so that the user is made aware of the fact
+   that a possibly unsafe action is being requested.
+
+   Naturally, it is not possible to ensure that the server does not
+   generate side-effects as a result of performing a GET request; in
+
+
+
+Fielding, et. al.           Standards Track                    [Page 48]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   fact, some dynamic resources consider that a feature. The important
+   distinction here is that the user did not request the side-effects,
+   so therefore cannot be held accountable for them.
+
+9.1.2 Idempotent Methods
+
+   Methods may also have the property of "idempotence" in that (aside
+   from error or expiration issues) the side-effects of  N > 0 identical
+   requests is the same as for a single request. The methods GET, HEAD,
+   PUT and DELETE share this property.
+
+9.2 OPTIONS
+
+   The OPTIONS method represents a request for information about the
+   communication options available on the request/response chain
+   identified by the Request-URI. This method allows the client to
+   determine the options and/or requirements associated with a resource,
+   or the capabilities of a server, without implying a resource action
+   or initiating a resource retrieval.
+
+   Unless the server's response is an error, the response MUST NOT
+   include entity information other than what can be considered as
+   communication options (e.g., Allow is appropriate, but Content-Type
+   is not). Responses to this method are not cachable.
+
+   If the Request-URI is an asterisk ("*"), the OPTIONS request is
+   intended to apply to the server as a whole. A 200 response SHOULD
+   include any header fields which indicate optional features
+   implemented by the server (e.g., Public), including any extensions
+   not defined by this specification, in addition to any applicable
+   general or response-header fields. As described in section 5.1.2, an
+   "OPTIONS *" request can be applied through a proxy by specifying the
+   destination server in the Request-URI without any path information.
+
+   If the Request-URI is not an asterisk, the OPTIONS request applies
+   only to the options that are available when communicating with that
+   resource.  A 200 response SHOULD include any header fields which
+   indicate optional features implemented by the server and applicable
+   to that resource (e.g., Allow), including any extensions not defined
+   by this specification, in addition to any applicable general or
+   response-header fields. If the OPTIONS request passes through a
+   proxy, the proxy MUST edit the response to exclude those options
+   which apply to a proxy's capabilities and which are known to be
+   unavailable through that proxy.
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 49]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+9.3 GET
+
+   The GET method means retrieve whatever information (in the form of an
+   entity) is identified by the Request-URI. If the Request-URI refers
+   to a data-producing process, it is the produced data which shall be
+   returned as the entity in the response and not the source text of the
+   process, unless that text happens to be the output of the process.
+
+   The semantics of the GET method change to a "conditional GET" if the
+   request message includes an If-Modified-Since, If-Unmodified-Since,
+   If-Match, If-None-Match, or If-Range header field. A conditional GET
+   method requests that the entity be transferred only under the
+   circumstances described by the conditional header field(s). The
+   conditional GET method is intended to reduce unnecessary network
+   usage by allowing cached entities to be refreshed without requiring
+   multiple requests or transferring data already held by the client.
+
+   The semantics of the GET method change to a "partial GET" if the
+   request message includes a Range header field. A partial GET requests
+   that only part of the entity be transferred, as described in section
+   14.36. The partial GET method is intended to reduce unnecessary
+   network usage by allowing partially-retrieved entities to be
+   completed without transferring data already held by the client.
+
+   The response to a GET request is cachable if and only if it meets the
+   requirements for HTTP caching described in section 13.
+
+9.4 HEAD
+
+   The HEAD method is identical to GET except that the server MUST NOT
+   return a message-body in the response. The metainformation contained
+   in the HTTP headers in response to a HEAD request SHOULD be identical
+   to the information sent in response to a GET request. This method can
+   be used for obtaining metainformation about the entity implied by the
+   request without transferring the entity-body itself. This method is
+   often used for testing hypertext links for validity, accessibility,
+   and recent modification.
+
+   The response to a HEAD request may be cachable in the sense that the
+   information contained in the response may be used to update a
+   previously cached entity from that resource. If the new field values
+   indicate that the cached entity differs from the current entity (as
+   would be indicated by a change in Content-Length, Content-MD5, ETag
+   or Last-Modified), then the cache MUST treat the cache entry as
+   stale.
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 50]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+9.5 POST
+
+   The POST method is used to request that the destination server accept
+   the entity enclosed in the request as a new subordinate of the
+   resource identified by the Request-URI in the Request-Line. POST is
+   designed to allow a uniform method to cover the following functions:
+
+     o  Annotation of existing resources;
+
+     o  Posting a message to a bulletin board, newsgroup, mailing list,
+        or similar group of articles;
+
+     o  Providing a block of data, such as the result of submitting a
+        form, to a data-handling process;
+
+     o  Extending a database through an append operation.
+
+   The actual function performed by the POST method is determined by the
+   server and is usually dependent on the Request-URI. The posted entity
+   is subordinate to that URI in the same way that a file is subordinate
+   to a directory containing it, a news article is subordinate to a
+   newsgroup to which it is posted, or a record is subordinate to a
+   database.
+
+   The action performed by the POST method might not result in a
+   resource that can be identified by a URI. In this case, either 200
+   (OK) or 204 (No Content) is the appropriate response status,
+   depending on whether or not the response includes an entity that
+   describes the result.
+
+   If a resource has been created on the origin server, the response
+   SHOULD be 201 (Created) and contain an entity which describes the
+   status of the request and refers to the new resource, and a Location
+   header (see section 14.30).
+
+   Responses to this method are not cachable, unless the response
+   includes appropriate Cache-Control or Expires header fields. However,
+   the 303 (See Other) response can be used to direct the user agent to
+   retrieve a cachable resource.
+
+   POST requests must obey the message transmission requirements set out
+   in section 8.2.
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 51]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+9.6 PUT
+
+   The PUT method requests that the enclosed entity be stored under the
+   supplied Request-URI. If the Request-URI refers to an already
+   existing resource, the enclosed entity SHOULD be considered as a
+   modified version of the one residing on the origin server. If the
+   Request-URI does not point to an existing resource, and that URI is
+   capable of being defined as a new resource by the requesting user
+   agent, the origin server can create the resource with that URI. If a
+   new resource is created, the origin server MUST inform the user agent
+   via the 201 (Created) response.  If an existing resource is modified,
+   either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
+   to indicate successful completion of the request. If the resource
+   could not be created or modified with the Request-URI, an appropriate
+   error response SHOULD be given that reflects the nature of the
+   problem. The recipient of the entity MUST NOT ignore any Content-*
+   (e.g. Content-Range) headers that it does not understand or implement
+   and MUST return a 501 (Not Implemented) response in such cases.
+
+   If the request passes through a cache and the Request-URI identifies
+   one or more currently cached entities, those entries should be
+   treated as stale. Responses to this method are not cachable.
+
+   The fundamental difference between the POST and PUT requests is
+   reflected in the different meaning of the Request-URI. The URI in a
+   POST request identifies the resource that will handle the enclosed
+   entity.  That resource may be a data-accepting process, a gateway to
+   some other protocol, or a separate entity that accepts annotations.
+   In contrast, the URI in a PUT request identifies the entity enclosed
+   with the request -- the user agent knows what URI is intended and the
+   server MUST NOT attempt to apply the request to some other resource.
+   If the server desires that the request be applied to a different URI,
+   it MUST send a 301 (Moved Permanently) response; the user agent MAY
+   then make its own decision regarding whether or not to redirect the
+   request.
+
+   A single resource MAY be identified by many different URIs. For
+   example, an article may have a URI for identifying "the current
+   version" which is separate from the URI identifying each particular
+   version. In this case, a PUT request on a general URI may result in
+   several other URIs being defined by the origin server.
+
+   HTTP/1.1 does not define how a PUT method affects the state of an
+   origin server.
+
+   PUT requests must obey the message transmission requirements set out
+   in section 8.2.
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 52]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+9.7 DELETE
+
+   The DELETE method requests that the origin server delete the resource
+   identified by the Request-URI. This method MAY be overridden by human
+   intervention (or other means) on the origin server. The client cannot
+   be guaranteed that the operation has been carried out, even if the
+   status code returned from the origin server indicates that the action
+   has been completed successfully. However, the server SHOULD not
+   indicate success unless, at the time the response is given, it
+   intends to delete the resource or move it to an inaccessible
+   location.
+
+   A successful response SHOULD be 200 (OK) if the response includes an
+   entity describing the status, 202 (Accepted) if the action has not
+   yet been enacted, or 204 (No Content) if the response is OK but does
+   not include an entity.
+
+   If the request passes through a cache and the Request-URI identifies
+   one or more currently cached entities, those entries should be
+   treated as stale. Responses to this method are not cachable.
+
+9.8 TRACE
+
+   The TRACE method is used to invoke a remote, application-layer loop-
+   back of the request message. The final recipient of the request
+   SHOULD reflect the message received back to the client as the
+   entity-body of a 200 (OK) response. The final recipient is either the
+   origin server or the first proxy or gateway to receive a Max-Forwards
+   value of zero (0) in the request (see section 14.31). A TRACE request
+   MUST NOT include an entity.
+
+   TRACE allows the client to see what is being received at the other
+   end of the request chain and use that data for testing or diagnostic
+   information. The value of the Via header field (section 14.44) is of
+   particular interest, since it acts as a trace of the request chain.
+   Use of the Max-Forwards header field allows the client to limit the
+   length of the request chain, which is useful for testing a chain of
+   proxies forwarding messages in an infinite loop.
+
+   If successful, the response SHOULD contain the entire request message
+   in the entity-body, with a Content-Type of "message/http". Responses
+   to this method MUST NOT be cached.
+
+10 Status Code Definitions
+
+   Each Status-Code is described below, including a description of which
+   method(s) it can follow and any metainformation required in the
+   response.
+
+
+
+Fielding, et. al.           Standards Track                    [Page 53]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+10.1 Informational 1xx
+
+   This class of status code indicates a provisional response,
+   consisting only of the Status-Line and optional headers, and is
+   terminated by an empty line. Since HTTP/1.0 did not define any 1xx
+   status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
+   client except under experimental conditions.
+
+10.1.1 100 Continue
+
+   The client may continue with its request. This interim response is
+   used to inform the client that the initial part of the request has
+   been received and has not yet been rejected by the server. The client
+   SHOULD continue by sending the remainder of the request or, if the
+   request has already been completed, ignore this response. The server
+   MUST send a final response after the request has been completed.
+
+10.1.2 101 Switching Protocols
+
+   The server understands and is willing to comply with the client's
+   request, via the Upgrade message header field (section 14.41), for a
+   change in the application protocol being used on this connection. The
+   server will switch protocols to those defined by the response's
+   Upgrade header field immediately after the empty line which
+   terminates the 101 response.
+
+   The protocol should only be switched when it is advantageous to do
+   so.  For example, switching to a newer version of HTTP is
+   advantageous over older versions, and switching to a real-time,
+   synchronous protocol may be advantageous when delivering resources
+   that use such features.
+
+10.2 Successful 2xx
+
+   This class of status code indicates that the client's request was
+   successfully received, understood, and accepted.
+
+10.2.1 200 OK
+
+   The request has succeeded. The information returned with the response
+   is dependent on the method used in the request, for example:
+
+   GET  an entity corresponding to the requested resource is sent in the
+        response;
+
+   HEAD the entity-header fields corresponding to the requested resource
+        are sent in the response without any message-body;
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 54]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   POST an entity describing or containing the result of the action;
+
+   TRACE an entity containing the request message as received by the end
+        server.
+
+10.2.2 201 Created
+
+   The request has been fulfilled and resulted in a new resource being
+   created. The newly created resource can be referenced by the URI(s)
+   returned in the entity of the response, with the most specific URL
+   for the resource given by a Location header field. The origin server
+   MUST create the resource before returning the 201 status code. If the
+   action cannot be carried out immediately, the server should respond
+   with 202 (Accepted) response instead.
+
+10.2.3 202 Accepted
+
+   The request has been accepted for processing, but the processing has
+   not been completed. The request MAY or MAY NOT eventually be acted
+   upon, as it MAY be disallowed when processing actually takes place.
+   There is no facility for re-sending a status code from an
+   asynchronous operation such as this.
+
+   The 202 response is intentionally non-committal. Its purpose is to
+   allow a server to accept a request for some other process (perhaps a
+   batch-oriented process that is only run once per day) without
+   requiring that the user agent's connection to the server persist
+   until the process is completed. The entity returned with this
+   response SHOULD include an indication of the request's current status
+   and either a pointer to a status monitor or some estimate of when the
+   user can expect the request to be fulfilled.
+
+10.2.4 203 Non-Authoritative Information
+
+   The returned metainformation in the entity-header is not the
+   definitive set as available from the origin server, but is gathered
+   from a local or a third-party copy. The set presented MAY be a subset
+   or superset of the original version. For example, including local
+   annotation information about the resource MAY result in a superset of
+   the metainformation known by the origin server. Use of this response
+   code is not required and is only appropriate when the response would
+   otherwise be 200 (OK).
+
+10.2.5 204 No Content
+
+   The server has fulfilled the request but there is no new information
+   to send back. If the client is a user agent, it SHOULD NOT change its
+   document view from that which caused the request to be sent. This
+
+
+
+Fielding, et. al.           Standards Track                    [Page 55]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   response is primarily intended to allow input for actions to take
+   place without causing a change to the user agent's active document
+   view. The response MAY include new metainformation in the form of
+   entity-headers, which SHOULD apply to the document currently in the
+   user agent's active view.
+
+   The 204 response MUST NOT include a message-body, and thus is always
+   terminated by the first empty line after the header fields.
+
+10.2.6 205 Reset Content
+
+   The server has fulfilled the request and the user agent SHOULD reset
+   the document view which caused the request to be sent. This response
+   is primarily intended to allow input for actions to take place via
+   user input, followed by a clearing of the form in which the input is
+   given so that the user can easily initiate another input action. The
+   response MUST NOT include an entity.
+
+10.2.7 206 Partial Content
+
+   The server has fulfilled the partial GET request for the resource.
+   The request must have included a Range header field (section 14.36)
+   indicating the desired range. The response MUST include either a
+   Content-Range header field (section 14.17) indicating the range
+   included with this response, or a multipart/byteranges Content-Type
+   including Content-Range fields for each part. If multipart/byteranges
+   is not used, the Content-Length header field in the response MUST
+   match the actual number of OCTETs transmitted in the message-body.
+
+   A cache that does not support the Range and Content-Range headers
+   MUST NOT cache 206 (Partial) responses.
+
+10.3 Redirection 3xx
+
+   This class of status code indicates that further action needs to be
+   taken by the user agent in order to fulfill the request. The action
+   required MAY be carried out by the user agent without interaction
+   with the user if and only if the method used in the second request is
+   GET or HEAD. A user agent SHOULD NOT automatically redirect a request
+   more than 5 times, since such redirections usually indicate an
+   infinite loop.
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 56]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+10.3.1 300 Multiple Choices
+
+   The requested resource corresponds to any one of a set of
+   representations, each with its own specific location, and agent-
+   driven negotiation information (section 12) is being provided so that
+   the user (or user agent) can select a preferred representation and
+   redirect its request to that location.
+
+   Unless it was a HEAD request, the response SHOULD include an entity
+   containing a list of resource characteristics and location(s) from
+   which the user or user agent can choose the one most appropriate. The
+   entity format is specified by the media type given in the Content-
+   Type header field. Depending upon the format and the capabilities of
+   the user agent, selection of the most appropriate choice may be
+   performed automatically.  However, this specification does not define
+   any standard for such automatic selection.
+
+   If the server has a preferred choice of representation, it SHOULD
+   include the specific URL for that representation in the Location
+   field; user agents MAY use the Location field value for automatic
+   redirection.  This response is cachable unless indicated otherwise.
+
+10.3.2 301 Moved Permanently
+
+   The requested resource has been assigned a new permanent URI and any
+   future references to this resource SHOULD be done using one of the
+   returned URIs. Clients with link editing capabilities SHOULD
+   automatically re-link references to the Request-URI to one or more of
+   the new references returned by the server, where possible. This
+   response is cachable unless indicated otherwise.
+
+   If the new URI is a location, its URL SHOULD be given by the Location
+   field in the response. Unless the request method was HEAD, the entity
+   of the response SHOULD contain a short hypertext note with a
+   hyperlink to the new URI(s).
+
+   If the 301 status code is received in response to a request other
+   than GET or HEAD, the user agent MUST NOT automatically redirect the
+   request unless it can be confirmed by the user, since this might
+   change the conditions under which the request was issued.
+
+     Note: When automatically redirecting a POST request after receiving
+     a 301 status code, some existing HTTP/1.0 user agents will
+     erroneously change it into a GET request.
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 57]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+10.3.3 302 Moved Temporarily
+
+   The requested resource resides temporarily under a different URI.
+   Since the redirection may be altered on occasion, the client SHOULD
+   continue to use the Request-URI for future requests. This response is
+   only cachable if indicated by a Cache-Control or Expires header
+   field.
+
+   If the new URI is a location, its URL SHOULD be given by the Location
+   field in the response. Unless the request method was HEAD, the entity
+   of the response SHOULD contain a short hypertext note with a
+   hyperlink to the new URI(s).
+
+   If the 302 status code is received in response to a request other
+   than GET or HEAD, the user agent MUST NOT automatically redirect the
+   request unless it can be confirmed by the user, since this might
+   change the conditions under which the request was issued.
+
+     Note: When automatically redirecting a POST request after receiving
+     a 302 status code, some existing HTTP/1.0 user agents will
+     erroneously change it into a GET request.
+
+10.3.4 303 See Other
+
+   The response to the request can be found under a different URI and
+   SHOULD be retrieved using a GET method on that resource. This method
+   exists primarily to allow the output of a POST-activated script to
+   redirect the user agent to a selected resource. The new URI is not a
+   substitute reference for the originally requested resource. The 303
+   response is not cachable, but the response to the second (redirected)
+   request MAY be cachable.
+
+   If the new URI is a location, its URL SHOULD be given by the Location
+   field in the response. Unless the request method was HEAD, the entity
+   of the response SHOULD contain a short hypertext note with a
+   hyperlink to the new URI(s).
+
+10.3.5 304 Not Modified
+
+   If the client has performed a conditional GET request and access is
+   allowed, but the document has not been modified, the server SHOULD
+   respond with this status code. The response MUST NOT contain a
+   message-body.
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 58]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   The response MUST include the following header fields:
+
+  o  Date
+
+  o  ETag and/or Content-Location, if the header would have been sent in
+     a 200 response to the same request
+
+  o  Expires, Cache-Control, and/or Vary, if the field-value might
+     differ from that sent in any previous response for the same variant
+
+   If the conditional GET used a strong cache validator (see section
+   13.3.3), the response SHOULD NOT include other entity-headers.
+   Otherwise (i.e., the conditional GET used a weak validator), the
+   response MUST NOT include other entity-headers; this prevents
+   inconsistencies between cached entity-bodies and updated headers.
+
+   If a 304 response indicates an entity not currently cached, then the
+   cache MUST disregard the response and repeat the request without the
+   conditional.
+
+   If a cache uses a received 304 response to update a cache entry, the
+   cache MUST update the entry to reflect any new field values given in
+   the response.
+
+   The 304 response MUST NOT include a message-body, and thus is always
+   terminated by the first empty line after the header fields.
+
+10.3.6 305 Use Proxy
+
+   The requested resource MUST be accessed through the proxy given by
+   the Location field. The Location field gives the URL of the proxy.
+   The recipient is expected to repeat the request via the proxy.
+
+10.4 Client Error 4xx
+
+   The 4xx class of status code is intended for cases in which the
+   client seems to have erred. Except when responding to a HEAD request,
+   the server SHOULD include an entity containing an explanation of the
+   error situation, and whether it is a temporary or permanent
+   condition. These status codes are applicable to any request method.
+   User agents SHOULD display any included entity to the user.
+
+     Note: If the client is sending data, a server implementation using
+     TCP should be careful to ensure that the client acknowledges
+     receipt of the packet(s) containing the response, before the server
+     closes the input connection. If the client continues sending data
+     to the server after the close, the server's TCP stack will send a
+     reset packet to the client, which may erase the client's
+
+
+
+Fielding, et. al.           Standards Track                    [Page 59]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+     unacknowledged input buffers before they can be read and
+     interpreted by the HTTP application.
+
+10.4.1 400 Bad Request
+
+   The request could not be understood by the server due to malformed
+   syntax. The client SHOULD NOT repeat the request without
+   modifications.
+
+10.4.2 401 Unauthorized
+
+   The request requires user authentication. The response MUST include a
+   WWW-Authenticate header field (section 14.46) containing a challenge
+   applicable to the requested resource. The client MAY repeat the
+   request with a suitable Authorization header field (section 14.8). If
+   the request already included Authorization credentials, then the 401
+   response indicates that authorization has been refused for those
+   credentials. If the 401 response contains the same challenge as the
+   prior response, and the user agent has already attempted
+   authentication at least once, then the user SHOULD be presented the
+   entity that was given in the response, since that entity MAY include
+   relevant diagnostic information. HTTP access authentication is
+   explained in section 11.
+
+10.4.3 402 Payment Required
+
+   This code is reserved for future use.
+
+10.4.4 403 Forbidden
+
+   The server understood the request, but is refusing to fulfill it.
+   Authorization will not help and the request SHOULD NOT be repeated.
+   If the request method was not HEAD and the server wishes to make
+   public why the request has not been fulfilled, it SHOULD describe the
+   reason for the refusal in the entity. This status code is commonly
+   used when the server does not wish to reveal exactly why the request
+   has been refused, or when no other response is applicable.
+
+10.4.5 404 Not Found
+
+   The server has not found anything matching the Request-URI. No
+   indication is given of whether the condition is temporary or
+   permanent.
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 60]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   If the server does not wish to make this information available to the
+   client, the status code 403 (Forbidden) can be used instead. The 410
+   (Gone) status code SHOULD be used if the server knows, through some
+   internally configurable mechanism, that an old resource is
+   permanently unavailable and has no forwarding address.
+
+10.4.6 405 Method Not Allowed
+
+   The method specified in the Request-Line is not allowed for the
+   resource identified by the Request-URI. The response MUST include an
+   Allow header containing a list of valid methods for the requested
+   resource.
+
+10.4.7 406 Not Acceptable
+
+   The resource identified by the request is only capable of generating
+   response entities which have content characteristics not acceptable
+   according to the accept headers sent in the request.
+
+   Unless it was a HEAD request, the response SHOULD include an entity
+   containing a list of available entity characteristics and location(s)
+   from which the user or user agent can choose the one most
+   appropriate.  The entity format is specified by the media type given
+   in the Content-Type header field. Depending upon the format and the
+   capabilities of the user agent, selection of the most appropriate
+   choice may be performed automatically. However, this specification
+   does not define any standard for such automatic selection.
+
+     Note: HTTP/1.1 servers are allowed to return responses which are
+     not acceptable according to the accept headers sent in the request.
+     In some cases, this may even be preferable to sending a 406
+     response. User agents are encouraged to inspect the headers of an
+     incoming response to determine if it is acceptable. If the response
+     could be unacceptable, a user agent SHOULD temporarily stop receipt
+     of more data and query the user for a decision on further actions.
+
+10.4.8 407 Proxy Authentication Required
+
+   This code is similar to 401 (Unauthorized), but indicates that the
+   client MUST first authenticate itself with the proxy. The proxy MUST
+   return a Proxy-Authenticate header field (section 14.33) containing a
+   challenge applicable to the proxy for the requested resource. The
+   client MAY repeat the request with a suitable Proxy-Authorization
+   header field (section 14.34). HTTP access authentication is explained
+   in section 11.
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 61]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+10.4.9 408 Request Timeout
+
+   The client did not produce a request within the time that the server
+   was prepared to wait. The client MAY repeat the request without
+   modifications at any later time.
+
+10.4.10 409 Conflict
+
+   The request could not be completed due to a conflict with the current
+   state of the resource. This code is only allowed in situations where
+   it is expected that the user might be able to resolve the conflict
+   and resubmit the request. The response body SHOULD include enough
+   information for the user to recognize the source of the conflict.
+   Ideally, the response entity would include enough information for the
+   user or user agent to fix the problem; however, that may not be
+   possible and is not required.
+
+   Conflicts are most likely to occur in response to a PUT request. If
+   versioning is being used and the entity being PUT includes changes to
+   a resource which conflict with those made by an earlier (third-party)
+   request, the server MAY use the 409 response to indicate that it
+   can't complete the request. In this case, the response entity SHOULD
+   contain a list of the differences between the two versions in a
+   format defined by the response Content-Type.
+
+10.4.11 410 Gone
+
+   The requested resource is no longer available at the server and no
+   forwarding address is known. This condition SHOULD be considered
+   permanent. Clients with link editing capabilities SHOULD delete
+   references to the Request-URI after user approval. If the server does
+   not know, or has no facility to determine, whether or not the
+   condition is permanent, the status code 404 (Not Found) SHOULD be
+   used instead.  This response is cachable unless indicated otherwise.
+
+   The 410 response is primarily intended to assist the task of web
+   maintenance by notifying the recipient that the resource is
+   intentionally unavailable and that the server owners desire that
+   remote links to that resource be removed. Such an event is common for
+   limited-time, promotional services and for resources belonging to
+   individuals no longer working at the server's site. It is not
+   necessary to mark all permanently unavailable resources as "gone" or
+   to keep the mark for any length of time -- that is left to the
+   discretion of the server owner.
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 62]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+10.4.12 411 Length Required
+
+   The server refuses to accept the request without a defined Content-
+   Length. The client MAY repeat the request if it adds a valid
+   Content-Length header field containing the length of the message-body
+   in the request message.
+
+10.4.13 412 Precondition Failed
+
+   The precondition given in one or more of the request-header fields
+   evaluated to false when it was tested on the server. This response
+   code allows the client to place preconditions on the current resource
+   metainformation (header field data) and thus prevent the requested
+   method from being applied to a resource other than the one intended.
+
+10.4.14 413 Request Entity Too Large
+
+   The server is refusing to process a request because the request
+   entity is larger than the server is willing or able to process. The
+   server may close the connection to prevent the client from continuing
+   the request.
+
+   If the condition is temporary, the server SHOULD include a Retry-
+   After header field to indicate that it is temporary and after what
+   time the client may try again.
+
+10.4.15 414 Request-URI Too Long
+
+   The server is refusing to service the request because the Request-URI
+   is longer than the server is willing to interpret. This rare
+   condition is only likely to occur when a client has improperly
+   converted a POST request to a GET request with long query
+   information, when the client has descended into a URL "black hole" of
+   redirection (e.g., a redirected URL prefix that points to a suffix of
+   itself), or when the server is under attack by a client attempting to
+   exploit security holes present in some servers using fixed-length
+   buffers for reading or manipulating the Request-URI.
+
+10.4.16 415 Unsupported Media Type
+
+   The server is refusing to service the request because the entity of
+   the request is in a format not supported by the requested resource
+   for the requested method.
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 63]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+10.5 Server Error 5xx
+
+   Response status codes beginning with the digit "5" indicate cases in
+   which the server is aware that it has erred or is incapable of
+   performing the request. Except when responding to a HEAD request, the
+   server SHOULD include an entity containing an explanation of the
+   error situation, and whether it is a temporary or permanent
+   condition. User agents SHOULD display any included entity to the
+   user. These response codes are applicable to any request method.
+
+10.5.1 500 Internal Server Error
+
+   The server encountered an unexpected condition which prevented it
+   from fulfilling the request.
+
+10.5.2 501 Not Implemented
+
+   The server does not support the functionality required to fulfill the
+   request. This is the appropriate response when the server does not
+   recognize the request method and is not capable of supporting it for
+   any resource.
+
+10.5.3 502 Bad Gateway
+
+   The server, while acting as a gateway or proxy, received an invalid
+   response from the upstream server it accessed in attempting to
+   fulfill the request.
+
+10.5.4 503 Service Unavailable
+
+   The server is currently unable to handle the request due to a
+   temporary overloading or maintenance of the server. The implication
+   is that this is a temporary condition which will be alleviated after
+   some delay. If known, the length of the delay may be indicated in a
+   Retry-After header.  If no Retry-After is given, the client SHOULD
+   handle the response as it would for a 500 response.
+
+     Note: The existence of the 503 status code does not imply that a
+     server must use it when becoming overloaded. Some servers may wish
+     to simply refuse the connection.
+
+10.5.5 504 Gateway Timeout
+
+   The server, while acting as a gateway or proxy, did not receive a
+   timely response from the upstream server it accessed in attempting to
+   complete the request.
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 64]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+10.5.6 505 HTTP Version Not Supported
+
+   The server does not support, or refuses to support, the HTTP protocol
+   version that was used in the request message. The server is
+   indicating that it is unable or unwilling to complete the request
+   using the same major version as the client, as described in section
+   3.1, other than with this error message. The response SHOULD contain
+   an entity describing why that version is not supported and what other
+   protocols are supported by that server.
+
+11 Access Authentication
+
+   HTTP provides a simple challenge-response authentication mechanism
+   which MAY be used by a server to challenge a client request and by a
+   client to provide authentication information. It uses an extensible,
+   case-insensitive token to identify the authentication scheme,
+   followed by a comma-separated list of attribute-value pairs which
+   carry the parameters necessary for achieving authentication via that
+   scheme.
+
+          auth-scheme    = token
+
+          auth-param     = token "=" quoted-string
+
+   The 401 (Unauthorized) response message is used by an origin server
+   to challenge the authorization of a user agent. This response MUST
+   include a WWW-Authenticate header field containing at least one
+   challenge applicable to the requested resource.
+
+          challenge      = auth-scheme 1*SP realm *( "," auth-param )
+
+          realm          = "realm" "=" realm-value
+          realm-value    = quoted-string
+
+   The realm attribute (case-insensitive) is required for all
+   authentication schemes which issue a challenge. The realm value
+   (case-sensitive), in combination with the canonical root URL (see
+   section 5.1.2) of the server being accessed, defines the protection
+   space. These realms allow the protected resources on a server to be
+   partitioned into a set of protection spaces, each with its own
+   authentication scheme and/or authorization database. The realm value
+   is a string, generally assigned by the origin server, which may have
+   additional semantics specific to the authentication scheme.
+
+   A user agent that wishes to authenticate itself with a server--
+   usually, but not necessarily, after receiving a 401 or 411 response-
+   -MAY do so by including an Authorization header field with the
+   request. The Authorization field value consists of credentials
+
+
+
+Fielding, et. al.           Standards Track                    [Page 65]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   containing the authentication information of the user agent for the
+   realm of the resource being requested.
+
+          credentials    = basic-credentials
+                         | auth-scheme #auth-param
+
+   The domain over which credentials can be automatically applied by a
+   user agent is determined by the protection space. If a prior request
+   has been authorized, the same credentials MAY be reused for all other
+   requests within that protection space for a period of time determined
+   by the authentication scheme, parameters, and/or user preference.
+   Unless otherwise defined by the authentication scheme, a single
+   protection space cannot extend outside the scope of its server.
+
+   If the server does not wish to accept the credentials sent with a
+   request, it SHOULD return a 401 (Unauthorized) response. The response
+   MUST include a WWW-Authenticate header field containing the (possibly
+   new) challenge applicable to the requested resource and an entity
+   explaining the refusal.
+
+   The HTTP protocol does not restrict applications to this simple
+   challenge-response mechanism for access authentication. Additional
+   mechanisms MAY be used, such as encryption at the transport level or
+   via message encapsulation, and with additional header fields
+   specifying authentication information. However, these additional
+   mechanisms are not defined by this specification.
+
+   Proxies MUST be completely transparent regarding user agent
+   authentication. That is, they MUST forward the WWW-Authenticate and
+   Authorization headers untouched, and follow the rules found in
+   section 14.8.
+
+   HTTP/1.1 allows a client to pass authentication information to and
+   from a proxy via the Proxy-Authenticate and Proxy-Authorization
+   headers.
+
+11.1 Basic Authentication Scheme
+
+   The "basic" authentication scheme is based on the model that the user
+   agent must authenticate itself with a user-ID and a password for each
+   realm. The realm value should be considered an opaque string which
+   can only be compared for equality with other realms on that server.
+   The server will service the request only if it can validate the
+   user-ID and password for the protection space of the Request-URI.
+   There are no optional authentication parameters.
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 66]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Upon receipt of an unauthorized request for a URI within the
+   protection space, the server MAY respond with a challenge like the
+   following:
+
+          WWW-Authenticate: Basic realm="WallyWorld"
+
+   where "WallyWorld" is the string assigned by the server to identify
+   the protection space of the Request-URI.
+
+   To receive authorization, the client sends the userid and password,
+   separated by a single colon (":") character, within a base64  encoded
+   string in the credentials.
+
+          basic-credentials = "Basic" SP basic-cookie
+
+          basic-cookie   = <base64 [7] encoding of user-pass,
+                           except not limited to 76 char/line>
+
+          user-pass   = userid ":" password
+
+          userid      = *<TEXT excluding ":">
+
+          password    = *TEXT
+
+   Userids might be case sensitive.
+
+   If the user agent wishes to send the userid "Aladdin" and password
+   "open sesame", it would use the following header field:
+
+          Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
+
+   See section 15 for security considerations associated with Basic
+   authentication.
+
+11.2 Digest Authentication Scheme
+
+   A digest authentication for HTTP is specified in RFC 2069 [32].
+
+12 Content Negotiation
+
+   Most HTTP responses include an entity which contains information for
+   interpretation by a human user. Naturally, it is desirable to supply
+   the user with the "best available" entity corresponding to the
+   request.  Unfortunately for servers and caches, not all users have
+   the same preferences for what is "best," and not all user agents are
+   equally capable of rendering all entity types. For that reason, HTTP
+   has provisions for several mechanisms for "content negotiation" --
+   the process of selecting the best representation for a given response
+
+
+
+Fielding, et. al.           Standards Track                    [Page 67]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   when there are multiple representations available.
+
+     Note: This is not called "format negotiation" because the alternate
+     representations may be of the same media type, but use different
+     capabilities of that type, be in different languages, etc.
+
+   Any response containing an entity-body MAY be subject to negotiation,
+   including error responses.
+
+   There are two kinds of content negotiation which are possible in
+   HTTP: server-driven and agent-driven negotiation. These two kinds of
+   negotiation are orthogonal and thus may be used separately or in
+   combination. One method of combination, referred to as transparent
+   negotiation, occurs when a cache uses the agent-driven negotiation
+   information provided by the origin server in order to provide
+   server-driven negotiation for subsequent requests.
+
+12.1 Server-driven Negotiation
+
+   If the selection of the best representation for a response is made by
+   an algorithm located at the server, it is called server-driven
+   negotiation.  Selection is based on the available representations of
+   the response (the dimensions over which it can vary; e.g. language,
+   content-coding, etc.) and the contents of particular header fields in
+   the request message or on other information pertaining to the request
+   (such as the network address of the client).
+
+   Server-driven negotiation is advantageous when the algorithm for
+   selecting from among the available representations is difficult to
+   describe to the user agent, or when the server desires to send its
+   "best guess" to the client along with the first response (hoping to
+   avoid the round-trip delay of a subsequent request if the "best
+   guess" is good enough for the user). In order to improve the server's
+   guess, the user agent MAY include request header fields (Accept,
+   Accept-Language, Accept-Encoding, etc.) which describe its
+   preferences for such a response.
+
+   Server-driven negotiation has disadvantages:
+
+1. It is impossible for the server to accurately determine what might be
+  "best" for any given user, since that would require complete
+  knowledge of both the capabilities of the user agent and the intended
+  use for the response (e.g., does the user want to view it on screen
+  or print it on paper?).
+
+2. Having the user agent describe its capabilities in every request can
+  be both very inefficient (given that only a small percentage of
+  responses have multiple representations) and a potential violation of
+
+
+
+Fielding, et. al.           Standards Track                    [Page 68]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+  the user's privacy.
+
+3. It complicates the implementation of an origin server and the
+  algorithms for generating responses to a request.
+
+4. It may limit a public cache's ability to use the same response for
+  multiple user's requests.
+
+   HTTP/1.1 includes the following request-header fields for enabling
+   server-driven negotiation through description of user agent
+   capabilities and user preferences: Accept (section 14.1), Accept-
+   Charset (section 14.2), Accept-Encoding (section 14.3), Accept-
+   Language (section 14.4), and User-Agent (section 14.42). However, an
+   origin server is not limited to these dimensions and MAY vary the
+   response based on any aspect of the request, including information
+   outside the request-header fields or within extension header fields
+   not defined by this specification.
+
+   HTTP/1.1 origin servers MUST include an appropriate Vary header field
+   (section 14.43) in any cachable response based on server-driven
+   negotiation. The Vary header field describes the dimensions over
+   which the response might vary (i.e. the dimensions over which the
+   origin server picks its "best guess" response from multiple
+   representations).
+
+   HTTP/1.1 public caches MUST recognize the Vary header field when it
+   is included in a response and obey the requirements described in
+   section 13.6 that describes the interactions between caching and
+   content negotiation.
+
+12.2 Agent-driven Negotiation
+
+   With agent-driven negotiation, selection of the best representation
+   for a response is performed by the user agent after receiving an
+   initial response from the origin server. Selection is based on a list
+   of the available representations of the response included within the
+   header fields (this specification reserves the field-name Alternates,
+   as described in appendix 19.6.2.1) or entity-body of the initial
+   response, with each representation identified by its own URI.
+   Selection from among the representations may be performed
+   automatically (if the user agent is capable of doing so) or manually
+   by the user selecting from a generated (possibly hypertext) menu.
+
+   Agent-driven negotiation is advantageous when the response would vary
+   over commonly-used dimensions (such as type, language, or encoding),
+   when the origin server is unable to determine a user agent's
+   capabilities from examining the request, and generally when public
+   caches are used to distribute server load and reduce network usage.
+
+
+
+Fielding, et. al.           Standards Track                    [Page 69]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Agent-driven negotiation suffers from the disadvantage of needing a
+   second request to obtain the best alternate representation. This
+   second request is only efficient when caching is used. In addition,
+   this specification does not define any mechanism for supporting
+   automatic selection, though it also does not prevent any such
+   mechanism from being developed as an extension and used within
+   HTTP/1.1.
+
+   HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
+   status codes for enabling agent-driven negotiation when the server is
+   unwilling or unable to provide a varying response using server-driven
+   negotiation.
+
+12.3 Transparent Negotiation
+
+   Transparent negotiation is a combination of both server-driven and
+   agent-driven negotiation. When a cache is supplied with a form of the
+   list of available representations of the response (as in agent-driven
+   negotiation) and the dimensions of variance are completely understood
+   by the cache, then the cache becomes capable of performing server-
+   driven negotiation on behalf of the origin server for subsequent
+   requests on that resource.
+
+   Transparent negotiation has the advantage of distributing the
+   negotiation work that would otherwise be required of the origin
+   server and also removing the second request delay of agent-driven
+   negotiation when the cache is able to correctly guess the right
+   response.
+
+   This specification does not define any mechanism for transparent
+   negotiation, though it also does not prevent any such mechanism from
+   being developed as an extension and used within HTTP/1.1. An HTTP/1.1
+   cache performing transparent negotiation MUST include a Vary header
+   field in the response (defining the dimensions of its variance) if it
+   is cachable to ensure correct interoperation with all HTTP/1.1
+   clients. The agent-driven negotiation information supplied by the
+   origin server SHOULD be included with the transparently negotiated
+   response.
+
+13 Caching in HTTP
+
+   HTTP is typically used for distributed information systems, where
+   performance can be improved by the use of response caches. The
+   HTTP/1.1 protocol includes a number of elements intended to make
+   caching work as well as possible. Because these elements are
+   inextricable from other aspects of the protocol, and because they
+   interact with each other, it is useful to describe the basic caching
+   design of HTTP separately from the detailed descriptions of methods,
+
+
+
+Fielding, et. al.           Standards Track                    [Page 70]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   headers, response codes, etc.
+
+   Caching would be useless if it did not significantly improve
+   performance. The goal of caching in HTTP/1.1 is to eliminate the need
+   to send requests in many cases, and to eliminate the need to send
+   full responses in many other cases. The former reduces the number of
+   network round-trips required for many operations; we use an
+   "expiration" mechanism for this purpose (see section 13.2). The
+   latter reduces network bandwidth requirements; we use a "validation"
+   mechanism for this purpose (see section 13.3).
+
+   Requirements for performance, availability, and disconnected
+   operation require us to be able to relax the goal of semantic
+   transparency. The HTTP/1.1 protocol allows origin servers, caches,
+   and clients to explicitly reduce transparency when necessary.
+   However, because non-transparent operation may confuse non-expert
+   users, and may be incompatible with certain server applications (such
+   as those for ordering merchandise), the protocol requires that
+   transparency be relaxed
+
+  o  only by an explicit protocol-level request when relaxed by client
+     or origin server
+
+  o  only with an explicit warning to the end user when relaxed by cache
+     or client
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 71]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Therefore, the HTTP/1.1 protocol provides these important elements:
+
+  1. Protocol features that provide full semantic transparency when this
+     is required by all parties.
+
+  2. Protocol features that allow an origin server or user agent to
+     explicitly request and control non-transparent operation.
+
+  3. Protocol features that allow a cache to attach warnings to
+     responses that do not preserve the requested approximation of
+     semantic transparency.
+
+   A basic principle is that it must be possible for the clients to
+   detect any potential relaxation of semantic transparency.
+
+     Note: The server, cache, or client implementer may be faced with
+     design decisions not explicitly discussed in this specification. If
+     a decision may affect semantic transparency, the implementer ought
+     to err on the side of maintaining transparency unless a careful and
+     complete analysis shows significant benefits in breaking
+     transparency.
+
+13.1.1 Cache Correctness
+
+   A correct cache MUST respond to a request with the most up-to-date
+   response held by the cache that is appropriate to the request (see
+   sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
+   conditions:
+
+  1. It has been checked for equivalence with what the origin server
+     would have returned by revalidating the response with the origin
+     server (section 13.3);
+
+  2. It is "fresh enough" (see section 13.2). In the default case, this
+     means it meets the least restrictive freshness requirement of the
+     client, server, and cache (see section 14.9); if the origin server
+     so specifies, it is the freshness requirement of the origin server
+     alone.
+
+  3. It includes a warning if the freshness demand of the client or the
+     origin server is violated (see section 13.1.5 and 14.45).
+
+  4. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or
+     error (4xx or 5xx) response message.
+
+   If the cache can not communicate with the origin server, then a
+   correct cache SHOULD respond as above if the response can be
+   correctly served from the cache; if not it MUST return an error or
+
+
+
+Fielding, et. al.           Standards Track                    [Page 72]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   warning indicating that there was a communication failure.
+
+   If a cache receives a response (either an entire response, or a 304
+   (Not Modified) response) that it would normally forward to the
+   requesting client, and the received response is no longer fresh, the
+   cache SHOULD forward it to the requesting client without adding a new
+   Warning (but without removing any existing Warning headers). A cache
+   SHOULD NOT attempt to revalidate a response simply because that
+   response became stale in transit; this might lead to an infinite
+   loop. An user agent that receives a stale response without a Warning
+   MAY display a warning indication to the user.
+
+13.1.2 Warnings
+
+   Whenever a cache returns a response that is neither first-hand nor
+   "fresh enough" (in the sense of condition 2 in section 13.1.1), it
+   must attach a warning to that effect, using a Warning response-
+   header. This warning allows clients to take appropriate action.
+
+   Warnings may be used for other purposes, both cache-related and
+   otherwise. The use of a warning, rather than an error status code,
+   distinguish these responses from true failures.
+
+   Warnings are always cachable, because they never weaken the
+   transparency of a response. This means that warnings can be passed to
+   HTTP/1.0 caches without danger; such caches will simply pass the
+   warning along as an entity-header in the response.
+
+   Warnings are assigned numbers between 0 and 99. This specification
+   defines the code numbers and meanings of each currently assigned
+   warnings, allowing a client or cache to take automated action in some
+   (but not all) cases.
+
+   Warnings also carry a warning text. The text may be in any
+   appropriate natural language (perhaps based on the client's Accept
+   headers), and include an optional indication of what character set is
+   used.
+
+   Multiple warnings may be attached to a response (either by the origin
+   server or by a cache), including multiple warnings with the same code
+   number. For example, a server may provide the same warning with texts
+   in both English and Basque.
+
+   When multiple warnings are attached to a response, it may not be
+   practical or reasonable to display all of them to the user. This
+   version of HTTP does not specify strict priority rules for deciding
+   which warnings to display and in what order, but does suggest some
+   heuristics.
+
+
+
+Fielding, et. al.           Standards Track                    [Page 73]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   The Warning header and the currently defined warnings are described
+   in section 14.45.
+
+13.1.3 Cache-control Mechanisms
+
+   The basic cache mechanisms in HTTP/1.1 (server-specified expiration
+   times and validators) are implicit directives to caches. In some
+   cases, a server or client may need to provide explicit directives to
+   the HTTP caches. We use the Cache-Control header for this purpose.
+
+   The Cache-Control header allows a client or server to transmit a
+   variety of directives in either requests or responses. These
+   directives typically override the default caching algorithms. As a
+   general rule, if there is any apparent conflict between header
+   values, the most restrictive interpretation should be applied (that
+   is, the one that is most likely to preserve semantic transparency).
+   However, in some cases, Cache-Control directives are explicitly
+   specified as weakening the approximation of semantic transparency
+   (for example, "max-stale" or "public").
+
+   The Cache-Control directives are described in detail in section 14.9.
+
+13.1.4 Explicit User Agent Warnings
+
+   Many user agents make it possible for users to override the basic
+   caching mechanisms. For example, the user agent may allow the user to
+   specify that cached entities (even explicitly stale ones) are never
+   validated. Or the user agent might habitually add "Cache-Control:
+   max-stale=3600" to every request. The user should have to explicitly
+   request either non-transparent behavior, or behavior that results in
+   abnormally ineffective caching.
+
+   If the user has overridden the basic caching mechanisms, the user
+   agent should explicitly indicate to the user whenever this results in
+   the display of information that might not meet the server's
+   transparency requirements (in particular, if the displayed entity is
+   known to be stale). Since the protocol normally allows the user agent
+   to determine if responses are stale or not, this indication need only
+   be displayed when this actually happens. The indication need not be a
+   dialog box; it could be an icon (for example, a picture of a rotting
+   fish) or some other visual indicator.
+
+   If the user has overridden the caching mechanisms in a way that would
+   abnormally reduce the effectiveness of caches, the user agent should
+   continually display an indication (for example, a picture of currency
+   in flames) so that the user does not inadvertently consume excess
+   resources or suffer from excessive latency.
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 74]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+13.1.5 Exceptions to the Rules and Warnings
+
+   In some cases, the operator of a cache may choose to configure it to
+   return stale responses even when not requested by clients. This
+   decision should not be made lightly, but may be necessary for reasons
+   of availability or performance, especially when the cache is poorly
+   connected to the origin server. Whenever a cache returns a stale
+   response, it MUST mark it as such (using a Warning header). This
+   allows the client software to alert the user that there may be a
+   potential problem.
+
+   It also allows the user agent to take steps to obtain a first-hand or
+   fresh response. For this reason, a cache SHOULD NOT return a stale
+   response if the client explicitly requests a first-hand or fresh one,
+   unless it is impossible to comply for technical or policy reasons.
+
+13.1.6 Client-controlled Behavior
+
+   While the origin server (and to a lesser extent, intermediate caches,
+   by their contribution to the age of a response) are the primary
+   source of expiration information, in some cases the client may need
+   to control a cache's decision about whether to return a cached
+   response without validating it. Clients do this using several
+   directives of the Cache-Control header.
+
+   A client's request may specify the maximum age it is willing to
+   accept of an unvalidated response; specifying a value of zero forces
+   the cache(s) to revalidate all responses. A client may also specify
+   the minimum time remaining before a response expires. Both of these
+   options increase constraints on the behavior of caches, and so cannot
+   further relax the cache's approximation of semantic transparency.
+
+   A client may also specify that it will accept stale responses, up to
+   some maximum amount of staleness. This loosens the constraints on the
+   caches, and so may violate the origin server's specified constraints
+   on semantic transparency, but may be necessary to support
+   disconnected operation, or high availability in the face of poor
+   connectivity.
+
+13.2 Expiration Model
+
+13.2.1 Server-Specified Expiration
+
+   HTTP caching works best when caches can entirely avoid making
+   requests to the origin server. The primary mechanism for avoiding
+   requests is for an origin server to provide an explicit expiration
+   time in the future, indicating that a response may be used to satisfy
+   subsequent requests.  In other words, a cache can return a fresh
+
+
+
+Fielding, et. al.           Standards Track                    [Page 75]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   response without first contacting the server.
+
+   Our expectation is that servers will assign future explicit
+   expiration times to responses in the belief that the entity is not
+   likely to change, in a semantically significant way, before the
+   expiration time is reached. This normally preserves semantic
+   transparency, as long as the server's expiration times are carefully
+   chosen.
+
+   The expiration mechanism applies only to responses taken from a cache
+   and not to first-hand responses forwarded immediately to the
+   requesting client.
+
+   If an origin server wishes to force a semantically transparent cache
+   to validate every request, it may assign an explicit expiration time
+   in the past. This means that the response is always stale, and so the
+   cache SHOULD validate it before using it for subsequent requests. See
+   section 14.9.4 for a more restrictive way to force revalidation.
+
+   If an origin server wishes to force any HTTP/1.1 cache, no matter how
+   it is configured, to validate every request, it should use the
+   "must-revalidate" Cache-Control directive (see section 14.9).
+
+   Servers specify explicit expiration times using either the Expires
+   header, or the max-age directive of the Cache-Control header.
+
+   An expiration time cannot be used to force a user agent to refresh
+   its display or reload a resource; its semantics apply only to caching
+   mechanisms, and such mechanisms need only check a resource's
+   expiration status when a new request for that resource is initiated.
+   See section 13.13 for explanation of the difference between caches
+   and history mechanisms.
+
+13.2.2 Heuristic Expiration
+
+   Since origin servers do not always provide explicit expiration times,
+   HTTP caches typically assign heuristic expiration times, employing
+   algorithms that use other header values (such as the Last-Modified
+   time) to estimate a plausible expiration time. The HTTP/1.1
+   specification does not provide specific algorithms, but does impose
+   worst-case constraints on their results. Since heuristic expiration
+   times may compromise semantic transparency, they should be used
+   cautiously, and we encourage origin servers to provide explicit
+   expiration times as much as possible.
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 76]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+13.2.3 Age Calculations
+
+   In order to know if a cached entry is fresh, a cache needs to know if
+   its age exceeds its freshness lifetime. We discuss how to calculate
+   the latter in section 13.2.4; this section describes how to calculate
+   the age of a response or cache entry.
+
+   In this discussion, we use the term "now" to mean "the current value
+   of the clock at the host performing the calculation." Hosts that use
+   HTTP, but especially hosts running origin servers and caches, should
+   use NTP [28] or some similar protocol to synchronize their clocks to
+   a globally accurate time standard.
+
+   Also note that HTTP/1.1 requires origin servers to send a Date header
+   with every response, giving the time at which the response was
+   generated. We use the term "date_value" to denote the value of the
+   Date header, in a form appropriate for arithmetic operations.
+
+   HTTP/1.1 uses the Age response-header to help convey age information
+   between caches. The Age header value is the sender's estimate of the
+   amount of time since the response was generated at the origin server.
+   In the case of a cached response that has been revalidated with the
+   origin server, the Age value is based on the time of revalidation,
+   not of the original response.
+
+   In essence, the Age value is the sum of the time that the response
+   has been resident in each of the caches along the path from the
+   origin server, plus the amount of time it has been in transit along
+   network paths.
+
+   We use the term "age_value" to denote the value of the Age header, in
+   a form appropriate for arithmetic operations.
+
+   A response's age can be calculated in two entirely independent ways:
+
+     1. now minus date_value, if the local clock is reasonably well
+        synchronized to the origin server's clock. If the result is
+        negative, the result is replaced by zero.
+
+     2. age_value, if all of the caches along the response path
+        implement HTTP/1.1.
+
+   Given that we have two independent ways to compute the age of a
+   response when it is received, we can combine these as
+
+          corrected_received_age = max(now - date_value, age_value)
+
+   and as long as we have either nearly synchronized clocks or all-
+
+
+
+Fielding, et. al.           Standards Track                    [Page 77]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   HTTP/1.1 paths, one gets a reliable (conservative) result.
+
+   Note that this correction is applied at each HTTP/1.1 cache along the
+   path, so that if there is an HTTP/1.0 cache in the path, the correct
+   received age is computed as long as the receiving cache's clock is
+   nearly in sync. We don't need end-to-end clock synchronization
+   (although it is good to have), and there is no explicit clock
+   synchronization step.
+
+   Because of network-imposed delays, some significant interval may pass
+   from the time that a server generates a response and the time it is
+   received at the next outbound cache or client. If uncorrected, this
+   delay could result in improperly low ages.
+
+   Because the request that resulted in the returned Age value must have
+   been initiated prior to that Age value's generation, we can correct
+   for delays imposed by the network by recording the time at which the
+   request was initiated. Then, when an Age value is received, it MUST
+   be interpreted relative to the time the request was initiated, not
+   the time that the response was received. This algorithm results in
+   conservative behavior no matter how much delay is experienced. So, we
+   compute:
+
+         corrected_initial_age = corrected_received_age
+                               + (now - request_time)
+
+   where "request_time" is the time (according to the local clock) when
+   the request that elicited this response was sent.
+
+   Summary of age calculation algorithm, when a cache receives a
+   response:
+
+      /*
+       * age_value
+       *      is the value of Age: header received by the cache with
+       *              this response.
+       * date_value
+       *      is the value of the origin server's Date: header
+       * request_time
+       *      is the (local) time when the cache made the request
+       *              that resulted in this cached response
+       * response_time
+       *      is the (local) time when the cache received the
+       *              response
+       * now
+       *      is the current (local) time
+       */
+      apparent_age = max(0, response_time - date_value);
+
+
+
+Fielding, et. al.           Standards Track                    [Page 78]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+      corrected_received_age = max(apparent_age, age_value);
+      response_delay = response_time - request_time;
+      corrected_initial_age = corrected_received_age + response_delay;
+      resident_time = now - response_time;
+      current_age   = corrected_initial_age + resident_time;
+
+   When a cache sends a response, it must add to the
+   corrected_initial_age the amount of time that the response was
+   resident locally. It must then transmit this total age, using the Age
+   header, to the next recipient cache.
+
+     Note that a client cannot reliably tell that a response is first-
+     hand, but the presence of an Age header indicates that a response
+     is definitely not first-hand. Also, if the Date in a response is
+     earlier than the client's local request time, the response is
+     probably not first-hand (in the absence of serious clock skew).
+
+13.2.4 Expiration Calculations
+
+   In order to decide whether a response is fresh or stale, we need to
+   compare its freshness lifetime to its age. The age is calculated as
+   described in section 13.2.3; this section describes how to calculate
+   the freshness lifetime, and to determine if a response has expired.
+   In the discussion below, the values can be represented in any form
+   appropriate for arithmetic operations.
+
+   We use the term "expires_value" to denote the value of the Expires
+   header. We use the term "max_age_value" to denote an appropriate
+   value of the number of seconds carried by the max-age directive of
+   the Cache-Control header in a response (see section 14.10.
+
+   The max-age directive takes priority over Expires, so if max-age is
+   present in a response, the calculation is simply:
+
+         freshness_lifetime = max_age_value
+
+   Otherwise, if Expires is present in the response, the calculation is:
+
+         freshness_lifetime = expires_value - date_value
+
+   Note that neither of these calculations is vulnerable to clock skew,
+   since all of the information comes from the origin server.
+
+   If neither Expires nor Cache-Control: max-age appears in the
+   response, and the response does not include other restrictions on
+   caching, the cache MAY compute a freshness lifetime using a
+   heuristic. If the value is greater than 24 hours, the cache must
+   attach Warning 13 to any response whose age is more than 24 hours if
+
+
+
+Fielding, et. al.           Standards Track                    [Page 79]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   such warning has not already been added.
+
+   Also, if the response does have a Last-Modified time, the heuristic
+   expiration value SHOULD be no more than some fraction of the interval
+   since that time. A typical setting of this fraction might be 10%.
+
+   The calculation to determine if a response has expired is quite
+   simple:
+
+         response_is_fresh = (freshness_lifetime > current_age)
+
+13.2.5 Disambiguating Expiration Values
+
+   Because expiration values are assigned optimistically, it is possible
+   for two caches to contain fresh values for the same resource that are
+   different.
+
+   If a client performing a retrieval receives a non-first-hand response
+   for a request that was already fresh in its own cache, and the Date
+   header in its existing cache entry is newer than the Date on the new
+   response, then the client MAY ignore the response. If so, it MAY
+   retry the request with a "Cache-Control: max-age=0" directive (see
+   section 14.9), to force a check with the origin server.
+
+   If a cache has two fresh responses for the same representation with
+   different validators, it MUST use the one with the more recent Date
+   header. This situation may arise because the cache is pooling
+   responses from other caches, or because a client has asked for a
+   reload or a revalidation of an apparently fresh cache entry.
+
+13.2.6 Disambiguating Multiple Responses
+
+   Because a client may be receiving responses via multiple paths, so
+   that some responses flow through one set of caches and other
+   responses flow through a different set of caches, a client may
+   receive responses in an order different from that in which the origin
+   server sent them. We would like the client to use the most recently
+   generated response, even if older responses are still apparently
+   fresh.
+
+   Neither the entity tag nor the expiration value can impose an
+   ordering on responses, since it is possible that a later response
+   intentionally carries an earlier expiration time. However, the
+   HTTP/1.1 specification requires the transmission of Date headers on
+   every response, and the Date values are ordered to a granularity of
+   one second.
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 80]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   When a client tries to revalidate a cache entry, and the response it
+   receives contains a Date header that appears to be older than the one
+   for the existing entry, then the client SHOULD repeat the request
+   unconditionally, and include
+
+          Cache-Control: max-age=0
+
+   to force any intermediate caches to validate their copies directly
+   with the origin server, or
+
+          Cache-Control: no-cache
+
+   to force any intermediate caches to obtain a new copy from the origin
+   server.
+
+   If the Date values are equal, then the client may use either response
+   (or may, if it is being extremely prudent, request a new response).
+   Servers MUST NOT depend on clients being able to choose
+   deterministically between responses generated during the same second,
+   if their expiration times overlap.
+
+13.3 Validation Model
+
+   When a cache has a stale entry that it would like to use as a
+   response to a client's request, it first has to check with the origin
+   server (or possibly an intermediate cache with a fresh response) to
+   see if its cached entry is still usable. We call this "validating"
+   the cache entry.  Since we do not want to have to pay the overhead of
+   retransmitting the full response if the cached entry is good, and we
+   do not want to pay the overhead of an extra round trip if the cached
+   entry is invalid, the HTTP/1.1 protocol supports the use of
+   conditional methods.
+
+   The key protocol features for supporting conditional methods are
+   those concerned with "cache validators." When an origin server
+   generates a full response, it attaches some sort of validator to it,
+   which is kept with the cache entry. When a client (user agent or
+   proxy cache) makes a conditional request for a resource for which it
+   has a cache entry, it includes the associated validator in the
+   request.
+
+   The server then checks that validator against the current validator
+   for the entity, and, if they match, it responds with a special status
+   code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it
+   returns a full response (including entity-body). Thus, we avoid
+   transmitting the full response if the validator matches, and we avoid
+   an extra round trip if it does not match.
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 81]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+     Note: the comparison functions used to decide if validators match
+     are defined in section 13.3.3.
+
+   In HTTP/1.1, a conditional request looks exactly the same as a normal
+   request for the same resource, except that it carries a special
+   header (which includes the validator) that implicitly turns the
+   method (usually, GET) into a conditional.
+
+   The protocol includes both positive and negative senses of cache-
+   validating conditions. That is, it is possible to request either that
+   a method be performed if and only if a validator matches or if and
+   only if no validators match.
+
+     Note: a response that lacks a validator may still be cached, and
+     served from cache until it expires, unless this is explicitly
+     prohibited by a Cache-Control directive. However, a cache cannot do
+     a conditional retrieval if it does not have a validator for the
+     entity, which means it will not be refreshable after it expires.
+
+13.3.1 Last-modified Dates
+
+   The Last-Modified entity-header field value is often used as a cache
+   validator. In simple terms, a cache entry is considered to be valid
+   if the entity has not been modified since the Last-Modified value.
+
+13.3.2 Entity Tag Cache Validators
+
+   The ETag entity-header field value, an entity tag, provides for an
+   "opaque" cache validator. This may allow more reliable validation in
+   situations where it is inconvenient to store modification dates,
+   where the one-second resolution of HTTP date values is not
+   sufficient, or where the origin server wishes to avoid certain
+   paradoxes that may arise from the use of modification dates.
+
+   Entity Tags are described in section 3.11. The headers used with
+   entity tags are described in sections 14.20, 14.25, 14.26 and 14.43.
+
+13.3.3 Weak and Strong Validators
+
+   Since both origin servers and caches will compare two validators to
+   decide if they represent the same or different entities, one normally
+   would expect that if the entity (the entity-body or any entity-
+   headers) changes in any way, then the associated validator would
+   change as well.  If this is true, then we call this validator a
+   "strong validator."
+
+   However, there may be cases when a server prefers to change the
+   validator only on semantically significant changes, and not when
+
+
+
+Fielding, et. al.           Standards Track                    [Page 82]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   insignificant aspects of the entity change. A validator that does not
+   always change when the resource changes is a "weak validator."
+
+   Entity tags are normally "strong validators," but the protocol
+   provides a mechanism to tag an entity tag as "weak." One can think of
+   a strong validator as one that changes whenever the bits of an entity
+   changes, while a weak value changes whenever the meaning of an entity
+   changes.  Alternatively, one can think of a strong validator as part
+   of an identifier for a specific entity, while a weak validator is
+   part of an identifier for a set of semantically equivalent entities.
+
+     Note: One example of a strong validator is an integer that is
+     incremented in stable storage every time an entity is changed.
+
+     An entity's modification time, if represented with one-second
+     resolution, could be a weak validator, since it is possible that
+     the resource may be modified twice during a single second.
+
+     Support for weak validators is optional; however, weak validators
+     allow for more efficient caching of equivalent objects; for
+     example, a hit counter on a site is probably good enough if it is
+     updated every few days or weeks, and any value during that period
+     is likely "good enough" to be equivalent.
+
+     A "use" of a validator is either when a client generates a request
+     and includes the validator in a validating header field, or when a
+     server compares two validators.
+
+   Strong validators are usable in any context. Weak validators are only
+   usable in contexts that do not depend on exact equality of an entity.
+   For example, either kind is usable for a conditional GET of a full
+   entity. However, only a strong validator is usable for a sub-range
+   retrieval, since otherwise the client may end up with an internally
+   inconsistent entity.
+
+   The only function that the HTTP/1.1 protocol defines on validators is
+   comparison. There are two validator comparison functions, depending
+   on whether the comparison context allows the use of weak validators
+   or not:
+
+  o  The strong comparison function: in order to be considered equal,
+     both validators must be identical in every way, and neither may be
+     weak.
+  o  The weak comparison function: in order to be considered equal, both
+     validators must be identical in every way, but either or both of
+     them may be tagged as "weak" without affecting the result.
+
+   The weak comparison function MAY be used for simple (non-subrange)
+
+
+
+Fielding, et. al.           Standards Track                    [Page 83]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   GET requests. The strong comparison function MUST be used in all
+   other cases.
+
+   An entity tag is strong unless it is explicitly tagged as weak.
+   Section 3.11 gives the syntax for entity tags.
+
+   A Last-Modified time, when used as a validator in a request, is
+   implicitly weak unless it is possible to deduce that it is strong,
+   using the following rules:
+
+  o  The validator is being compared by an origin server to the actual
+     current validator for the entity and,
+  o  That origin server reliably knows that the associated entity did
+     not change twice during the second covered by the presented
+     validator.
+or
+
+  o  The validator is about to be used by a client in an If-Modified-
+     Since or If-Unmodified-Since header, because the client has a cache
+     entry for the associated entity, and
+  o  That cache entry includes a Date value, which gives the time when
+     the origin server sent the original response, and
+  o  The presented Last-Modified time is at least 60 seconds before the
+     Date value.
+or
+
+  o  The validator is being compared by an intermediate cache to the
+     validator stored in its cache entry for the entity, and
+  o  That cache entry includes a Date value, which gives the time when
+     the origin server sent the original response, and
+  o  The presented Last-Modified time is at least 60 seconds before the
+     Date value.
+
+   This method relies on the fact that if two different responses were
+   sent by the origin server during the same second, but both had the
+   same Last-Modified time, then at least one of those responses would
+   have a Date value equal to its Last-Modified time. The arbitrary 60-
+   second limit guards against the possibility that the Date and Last-
+   Modified values are generated from different clocks, or at somewhat
+   different times during the preparation of the response. An
+   implementation may use a value larger than 60 seconds, if it is
+   believed that 60 seconds is too short.
+
+   If a client wishes to perform a sub-range retrieval on a value for
+   which it has only a Last-Modified time and no opaque validator, it
+   may do this only if the Last-Modified time is strong in the sense
+   described here.
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 84]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   A cache or origin server receiving a cache-conditional request, other
+   than a full-body GET request, MUST use the strong comparison function
+   to evaluate the condition.
+
+   These rules allow HTTP/1.1 caches and clients to safely perform sub-
+   range retrievals on values that have been obtained from HTTP/1.0
+   servers.
+
+13.3.4 Rules for When to Use Entity Tags and Last-modified Dates
+
+   We adopt a set of rules and recommendations for origin servers,
+   clients, and caches regarding when various validator types should be
+   used, and for what purposes.
+
+   HTTP/1.1 origin servers:
+
+  o  SHOULD send an entity tag validator unless it is not feasible to
+     generate one.
+  o  MAY send a weak entity tag instead of a strong entity tag, if
+     performance considerations support the use of weak entity tags, or
+     if it is unfeasible to send a strong entity tag.
+  o  SHOULD send a Last-Modified value if it is feasible to send one,
+     unless the risk of a breakdown in semantic transparency that could
+     result from using this date in an If-Modified-Since header would
+     lead to serious problems.
+
+   In other words, the preferred behavior for an HTTP/1.1 origin server
+   is to send both a strong entity tag and a Last-Modified value.
+
+   In order to be legal, a strong entity tag MUST change whenever the
+   associated entity value changes in any way. A weak entity tag SHOULD
+   change whenever the associated entity changes in a semantically
+   significant way.
+
+     Note: in order to provide semantically transparent caching, an
+     origin server must avoid reusing a specific strong entity tag value
+     for two different entities, or reusing a specific weak entity tag
+     value for two semantically different entities. Cache entries may
+     persist for arbitrarily long periods, regardless of expiration
+     times, so it may be inappropriate to expect that a cache will never
+     again attempt to validate an entry using a validator that it
+     obtained at some point in the past.
+
+   HTTP/1.1 clients:
+
+     o  If an entity tag has been provided by the origin server, MUST
+        use that entity tag in any cache-conditional request (using
+        If-Match or If-None-Match).
+
+
+
+Fielding, et. al.           Standards Track                    [Page 85]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+     o  If only a Last-Modified value has been provided by the origin
+        server, SHOULD use that value in non-subrange cache-conditional
+        requests (using If-Modified-Since).
+     o  If only a Last-Modified value has been provided by an HTTP/1.0
+        origin server, MAY use that value in subrange cache-conditional
+        requests (using If-Unmodified-Since:). The user agent should
+        provide a way to disable this, in case of difficulty.
+     o  If both an entity tag and a Last-Modified value have been
+        provided by the origin server, SHOULD use both validators in
+        cache-conditional requests. This allows both HTTP/1.0 and
+        HTTP/1.1 caches to respond appropriately.
+
+   An HTTP/1.1 cache, upon receiving a request, MUST use the most
+   restrictive validator when deciding whether the client's cache entry
+   matches the cache's own cache entry. This is only an issue when the
+   request contains both an entity tag and a last-modified-date
+   validator (If-Modified-Since or If-Unmodified-Since).
+
+     A note on rationale: The general principle behind these rules is
+     that HTTP/1.1 servers and clients should transmit as much non-
+     redundant information as is available in their responses and
+     requests. HTTP/1.1 systems receiving this information will make the
+     most conservative assumptions about the validators they receive.
+
+     HTTP/1.0 clients and caches will ignore entity tags. Generally,
+     last-modified values received or used by these systems will support
+     transparent and efficient caching, and so HTTP/1.1 origin servers
+     should provide Last-Modified values. In those rare cases where the
+     use of a Last-Modified value as a validator by an HTTP/1.0 system
+     could result in a serious problem, then HTTP/1.1 origin servers
+     should not provide one.
+
+13.3.5 Non-validating Conditionals
+
+   The principle behind entity tags is that only the service author
+   knows the semantics of a resource well enough to select an
+   appropriate cache validation mechanism, and the specification of any
+   validator comparison function more complex than byte-equality would
+   open up a can of worms.  Thus, comparisons of any other headers
+   (except Last-Modified, for compatibility with HTTP/1.0) are never
+   used for purposes of validating a cache entry.
+
+13.4 Response Cachability
+
+   Unless specifically constrained by a Cache-Control (section 14.9)
+   directive, a caching system may always store a successful response
+   (see section 13.8) as a cache entry, may return it without validation
+   if it is fresh, and may return it after successful validation. If
+
+
+
+Fielding, et. al.           Standards Track                    [Page 86]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   there is neither a cache validator nor an explicit expiration time
+   associated with a response, we do not expect it to be cached, but
+   certain caches may violate this expectation (for example, when little
+   or no network connectivity is available). A client can usually detect
+   that such a response was taken from a cache by comparing the Date
+   header to the current time.
+
+     Note that some HTTP/1.0 caches are known to violate this
+     expectation without providing any Warning.
+
+   However, in some cases it may be inappropriate for a cache to retain
+   an entity, or to return it in response to a subsequent request. This
+   may be because absolute semantic transparency is deemed necessary by
+   the service author, or because of security or privacy considerations.
+   Certain Cache-Control directives are therefore provided so that the
+   server can indicate that certain resource entities, or portions
+   thereof, may not be cached regardless of other considerations.
+
+   Note that section 14.8 normally prevents a shared cache from saving
+   and returning a response to a previous request if that request
+   included an Authorization header.
+
+   A response received with a status code of 200, 203, 206, 300, 301 or
+   410 may be stored by a cache and used in reply to a subsequent
+   request, subject to the expiration mechanism, unless a Cache-Control
+   directive prohibits caching. However, a cache that does not support
+   the Range and Content-Range headers MUST NOT cache 206 (Partial
+   Content) responses.
+
+   A response received with any other status code MUST NOT be returned
+   in a reply to a subsequent request unless there are Cache-Control
+   directives or another header(s) that explicitly allow it. For
+   example, these include the following: an Expires header (section
+   14.21); a "max-age", "must-revalidate", "proxy-revalidate", "public"
+   or "private" Cache-Control directive (section 14.9).
+
+13.5 Constructing Responses From Caches
+
+   The purpose of an HTTP cache is to store information received in
+   response to requests, for use in responding to future requests. In
+   many cases, a cache simply returns the appropriate parts of a
+   response to the requester. However, if the cache holds a cache entry
+   based on a previous response, it may have to combine parts of a new
+   response with what is held in the cache entry.
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 87]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+13.5.1 End-to-end and Hop-by-hop Headers
+
+   For the purpose of defining the behavior of caches and non-caching
+   proxies, we divide HTTP headers into two categories:
+
+  o  End-to-end headers, which must be transmitted to the
+     ultimate recipient of a request or response. End-to-end
+     headers in responses must be stored as part of a cache entry
+     and transmitted in any response formed from a cache entry.
+  o  Hop-by-hop headers, which are meaningful only for a single
+     transport-level connection, and are not stored by caches or
+     forwarded by proxies.
+
+   The following HTTP/1.1 headers are hop-by-hop headers:
+
+     o  Connection
+     o  Keep-Alive
+     o  Public
+     o  Proxy-Authenticate
+     o  Transfer-Encoding
+     o  Upgrade
+
+   All other headers defined by HTTP/1.1 are end-to-end headers.
+
+   Hop-by-hop headers introduced in future versions of HTTP MUST be
+   listed in a Connection header, as described in section 14.10.
+
+13.5.2 Non-modifiable Headers
+
+   Some features of the HTTP/1.1 protocol, such as Digest
+   Authentication, depend on the value of certain end-to-end headers. A
+   cache or non-caching proxy SHOULD NOT modify an end-to-end header
+   unless the definition of that header requires or specifically allows
+   that.
+
+   A cache or non-caching proxy MUST NOT modify any of the following
+   fields in a request or response, nor may it add any of these fields
+   if not already present:
+
+     o  Content-Location
+     o  ETag
+     o  Expires
+     o  Last-Modified
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 88]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   A cache or non-caching proxy MUST NOT modify or add any of the
+   following fields in a response that contains the no-transform Cache-
+   Control directive, or in any request:
+
+     o  Content-Encoding
+     o  Content-Length
+     o  Content-Range
+     o  Content-Type
+
+   A cache or non-caching proxy MAY modify or add these fields in a
+   response that does not include no-transform, but if it does so, it
+   MUST add a Warning 14 (Transformation applied) if one does not
+   already appear in the response.
+
+     Warning: unnecessary modification of end-to-end headers may cause
+     authentication failures if stronger authentication mechanisms are
+     introduced in later versions of HTTP. Such authentication
+     mechanisms may rely on the values of header fields not listed here.
+
+13.5.3 Combining Headers
+
+   When a cache makes a validating request to a server, and the server
+   provides a 304 (Not Modified) response, the cache must construct a
+   response to send to the requesting client. The cache uses the
+   entity-body stored in the cache entry as the entity-body of this
+   outgoing response. The end-to-end headers stored in the cache entry
+   are used for the constructed response, except that any end-to-end
+   headers provided in the 304 response MUST replace the corresponding
+   headers from the cache entry. Unless the cache decides to remove the
+   cache entry, it MUST also replace the end-to-end headers stored with
+   the cache entry with corresponding headers received in the incoming
+   response.
+
+   In other words, the set of end-to-end headers received in the
+   incoming response overrides all corresponding end-to-end headers
+   stored with the cache entry. The cache may add Warning headers (see
+   section 14.45) to this set.
+
+   If a header field-name in the incoming response matches more than one
+   header in the cache entry, all such old headers are replaced.
+
+     Note: this rule allows an origin server to use a 304 (Not Modified)
+     response to update any header associated with a previous response
+     for the same entity, although it might not always be meaningful or
+     correct to do so. This rule does not allow an origin server to use
+     a 304 (not Modified) response to entirely delete a header that it
+     had provided with a previous response.
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 89]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+13.5.4 Combining Byte Ranges
+
+   A response may transfer only a subrange of the bytes of an entity-
+   body, either because the request included one or more Range
+   specifications, or because a connection was broken prematurely. After
+   several such transfers, a cache may have received several ranges of
+   the same entity-body.
+
+   If a cache has a stored non-empty set of subranges for an entity, and
+   an incoming response transfers another subrange, the cache MAY
+   combine the new subrange with the existing set if both the following
+   conditions are met:
+
+     o  Both the incoming response and the cache entry must have a cache
+        validator.
+     o  The two cache validators must match using the strong comparison
+        function (see section 13.3.3).
+
+   If either requirement is not meant, the cache must use only the most
+   recent partial response (based on the Date values transmitted with
+   every response, and using the incoming response if these values are
+   equal or missing), and must discard the other partial information.
+
+13.6 Caching Negotiated Responses
+
+   Use of server-driven content negotiation (section 12), as indicated
+   by the presence of a Vary header field in a response, alters the
+   conditions and procedure by which a cache can use the response for
+   subsequent requests.
+
+   A server MUST use the Vary header field (section 14.43) to inform a
+   cache of what header field dimensions are used to select among
+   multiple representations of a cachable response. A cache may use the
+   selected representation (the entity included with that particular
+   response) for replying to subsequent requests on that resource only
+   when the subsequent requests have the same or equivalent values for
+   all header fields specified in the Vary response-header. Requests
+   with a different value for one or more of those header fields would
+   be forwarded toward the origin server.
+
+   If an entity tag was assigned to the representation, the forwarded
+   request SHOULD be conditional and include the entity tags in an If-
+   None-Match header field from all its cache entries for the Request-
+   URI. This conveys to the server the set of entities currently held by
+   the cache, so that if any one of these entities matches the requested
+   entity, the server can use the ETag header in its 304 (Not Modified)
+   response to tell the cache which entry is appropriate. If the
+   entity-tag of the new response matches that of an existing entry, the
+
+
+
+Fielding, et. al.           Standards Track                    [Page 90]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   new response SHOULD be used to update the header fields of the
+   existing entry, and the result MUST be returned to the client.
+
+   The Vary header field may also inform the cache that the
+   representation was selected using criteria not limited to the
+   request-headers; in this case, a cache MUST NOT use the response in a
+   reply to a subsequent request unless the cache relays the new request
+   to the origin server in a conditional request and the server responds
+   with 304 (Not Modified), including an entity tag or Content-Location
+   that indicates which entity should be used.
+
+   If any of the existing cache entries contains only partial content
+   for the associated entity, its entity-tag SHOULD NOT be included in
+   the If-None-Match header unless the request is for a range that would
+   be fully satisfied by that entry.
+
+   If a cache receives a successful response whose Content-Location
+   field matches that of an existing cache entry for the same Request-
+   URI, whose entity-tag differs from that of the existing entry, and
+   whose Date is more recent than that of the existing entry, the
+   existing entry SHOULD NOT be returned in response to future requests,
+   and should be deleted from the cache.
+
+13.7 Shared and Non-Shared Caches
+
+   For reasons of security and privacy, it is necessary to make a
+   distinction between "shared" and "non-shared" caches. A non-shared
+   cache is one that is accessible only to a single user. Accessibility
+   in this case SHOULD be enforced by appropriate security mechanisms.
+   All other caches are considered to be "shared." Other sections of
+   this specification place certain constraints on the operation of
+   shared caches in order to prevent loss of privacy or failure of
+   access controls.
+
+13.8 Errors or Incomplete Response Cache Behavior
+
+   A cache that receives an incomplete response (for example, with fewer
+   bytes of data than specified in a Content-Length header) may store
+   the response. However, the cache MUST treat this as a partial
+   response.  Partial responses may be combined as described in section
+   13.5.4; the result might be a full response or might still be
+   partial. A cache MUST NOT return a partial response to a client
+   without explicitly marking it as such, using the 206 (Partial
+   Content) status code. A cache MUST NOT return a partial response
+   using a status code of 200 (OK).
+
+   If a cache receives a 5xx response while attempting to revalidate an
+   entry, it may either forward this response to the requesting client,
+
+
+
+Fielding, et. al.           Standards Track                    [Page 91]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   or act as if the server failed to respond. In the latter case, it MAY
+   return a previously received response unless the cached entry
+   includes the "must-revalidate" Cache-Control directive (see section
+   14.9).
+
+13.9 Side Effects of GET and HEAD
+
+   Unless the origin server explicitly prohibits the caching of their
+   responses, the application of GET and HEAD methods to any resources
+   SHOULD NOT have side effects that would lead to erroneous behavior if
+   these responses are taken from a cache. They may still have side
+   effects, but a cache is not required to consider such side effects in
+   its caching decisions. Caches are always expected to observe an
+   origin server's explicit restrictions on caching.
+
+   We note one exception to this rule: since some applications have
+   traditionally used GETs and HEADs with query URLs (those containing a
+   "?" in the rel_path part) to perform operations with significant side
+   effects, caches MUST NOT treat responses to such URLs as fresh unless
+   the server provides an explicit expiration time. This specifically
+   means that responses from HTTP/1.0 servers for such URIs should not
+   be taken from a cache. See section 9.1.1 for related information.
+
+13.10 Invalidation After Updates or Deletions
+
+   The effect of certain methods at the origin server may cause one or
+   more existing cache entries to become non-transparently invalid. That
+   is, although they may continue to be "fresh," they do not accurately
+   reflect what the origin server would return for a new request.
+
+   There is no way for the HTTP protocol to guarantee that all such
+   cache entries are marked invalid. For example, the request that
+   caused the change at the origin server may not have gone through the
+   proxy where a cache entry is stored. However, several rules help
+   reduce the likelihood of erroneous behavior.
+
+   In this section, the phrase "invalidate an entity" means that the
+   cache should either remove all instances of that entity from its
+   storage, or should mark these as "invalid" and in need of a mandatory
+   revalidation before they can be returned in response to a subsequent
+   request.
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 92]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Some HTTP methods may invalidate an entity. This is either the entity
+   referred to by the Request-URI, or by the Location or Content-
+   Location response-headers (if present). These methods are:
+
+     o  PUT
+     o  DELETE
+     o  POST
+
+   In order to prevent denial of service attacks, an invalidation based
+   on the URI in a Location or Content-Location header MUST only be
+   performed if the host part is the same as in the Request-URI.
+
+13.11 Write-Through Mandatory
+
+   All methods that may be expected to cause modifications to the origin
+   server's resources MUST be written through to the origin server. This
+   currently includes all methods except for GET and HEAD. A cache MUST
+   NOT reply to such a request from a client before having transmitted
+   the request to the inbound server, and having received a
+   corresponding response from the inbound server. This does not prevent
+   a cache from sending a 100 (Continue) response before the inbound
+   server has replied.
+
+   The alternative (known as "write-back" or "copy-back" caching) is not
+   allowed in HTTP/1.1, due to the difficulty of providing consistent
+   updates and the problems arising from server, cache, or network
+   failure prior to write-back.
+
+13.12 Cache Replacement
+
+   If a new cachable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8)
+   response is received from a resource while any existing responses for
+   the same resource are cached, the cache SHOULD use the new response
+   to reply to the current request. It may insert it into cache storage
+   and may, if it meets all other requirements, use it to respond to any
+   future requests that would previously have caused the old response to
+   be returned. If it inserts the new response into cache storage it
+   should follow the rules in section 13.5.3.
+
+     Note: a new response that has an older Date header value than
+     existing cached responses is not cachable.
+
+13.13 History Lists
+
+   User agents often have history mechanisms, such as "Back" buttons and
+   history lists, which can be used to redisplay an entity retrieved
+   earlier in a session.
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 93]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   History mechanisms and caches are different. In particular history
+   mechanisms SHOULD NOT try to show a semantically transparent view of
+   the current state of a resource. Rather, a history mechanism is meant
+   to show exactly what the user saw at the time when the resource was
+   retrieved.
+
+   By default, an expiration time does not apply to history mechanisms.
+   If the entity is still in storage, a history mechanism should display
+   it even if the entity has expired, unless the user has specifically
+   configured the agent to refresh expired history documents.
+
+   This should not be construed to prohibit the history mechanism from
+   telling the user that a view may be stale.
+
+     Note: if history list mechanisms unnecessarily prevent users from
+     viewing stale resources, this will tend to force service authors to
+     avoid using HTTP expiration controls and cache controls when they
+     would otherwise like to. Service authors may consider it important
+     that users not be presented with error messages or warning messages
+     when they use navigation controls (such as BACK) to view previously
+     fetched resources. Even though sometimes such resources ought not
+     to cached, or ought to expire quickly, user interface
+     considerations may force service authors to resort to other means
+     of preventing caching (e.g. "once-only" URLs) in order not to
+     suffer the effects of improperly functioning history mechanisms.
+
+14 Header Field Definitions
+
+   This section defines the syntax and semantics of all standard
+   HTTP/1.1 header fields. For entity-header fields, both sender and
+   recipient refer to either the client or the server, depending on who
+   sends and who receives the entity.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 94]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+14.1 Accept
+
+   The Accept request-header field can be used to specify certain media
+   types which are acceptable for the response. Accept headers can be
+   used to indicate that the request is specifically limited to a small
+   set of desired types, as in the case of a request for an in-line
+   image.
+
+          Accept         = "Accept" ":"
+                           #( media-range [ accept-params ] )
+
+          media-range    = ( "*/*"
+                           | ( type "/" "*" )
+                           | ( type "/" subtype )
+                           ) *( ";" parameter )
+
+          accept-params  = ";" "q" "=" qvalue *( accept-extension )
+
+          accept-extension = ";" token [ "=" ( token | quoted-string ) ]
+
+   The asterisk "*" character is used to group media types into ranges,
+   with "*/*" indicating all media types and "type/*" indicating all
+   subtypes of that type. The media-range MAY include media type
+   parameters that are applicable to that range.
+
+   Each media-range MAY be followed by one or more accept-params,
+   beginning with the "q" parameter for indicating a relative quality
+   factor. The first "q" parameter (if any) separates the media-range
+   parameter(s) from the accept-params. Quality factors allow the user
+   or user agent to indicate the relative degree of preference for that
+   media-range, using the qvalue scale from 0 to 1 (section 3.9). The
+   default value is q=1.
+
+     Note: Use of the "q" parameter name to separate media type
+     parameters from Accept extension parameters is due to historical
+     practice.  Although this prevents any media type parameter named
+     "q" from being used with a media range, such an event is believed
+     to be unlikely given the lack of any "q" parameters in the IANA
+     media type registry and the rare usage of any media type parameters
+     in Accept. Future media types should be discouraged from
+     registering any parameter named "q".
+
+   The example
+
+          Accept: audio/*; q=0.2, audio/basic
+
+   SHOULD be interpreted as "I prefer audio/basic, but send me any audio
+   type if it is the best available after an 80% mark-down in quality."
+
+
+
+Fielding, et. al.           Standards Track                    [Page 95]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   If no Accept header field is present, then it is assumed that the
+   client accepts all media types. If an Accept header field is present,
+   and if the server cannot send a response which is acceptable
+   according to the combined Accept field value, then the server SHOULD
+   send a 406 (not acceptable) response.
+
+   A more elaborate example is
+
+          Accept: text/plain; q=0.5, text/html,
+                  text/x-dvi; q=0.8, text/x-c
+
+   Verbally, this would be interpreted as "text/html and text/x-c are
+   the preferred media types, but if they do not exist, then send the
+   text/x-dvi entity, and if that does not exist, send the text/plain
+   entity."
+
+   Media ranges can be overridden by more specific media ranges or
+   specific media types. If more than one media range applies to a given
+   type, the most specific reference has precedence. For example,
+
+          Accept: text/*, text/html, text/html;level=1, */*
+
+   have the following precedence:
+
+          1) text/html;level=1
+          2) text/html
+          3) text/*
+          4) */*
+
+   The media type quality factor associated with a given type is
+   determined by finding the media range with the highest precedence
+   which matches that type. For example,
+
+          Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
+                  text/html;level=2;q=0.4, */*;q=0.5
+
+   would cause the following values to be associated:
+
+          text/html;level=1         = 1
+          text/html                 = 0.7
+          text/plain                = 0.3
+          image/jpeg                = 0.5
+          text/html;level=2         = 0.4
+          text/html;level=3         = 0.7
+
+     Note: A user agent may be provided with a default set of quality
+     values for certain media ranges. However, unless the user agent is
+     a closed system which cannot interact with other rendering agents,
+
+
+
+Fielding, et. al.           Standards Track                    [Page 96]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+     this default set should be configurable by the user.
+
+14.2 Accept-Charset
+
+   The Accept-Charset request-header field can be used to indicate what
+   character sets are acceptable for the response. This field allows
+   clients capable of understanding more comprehensive or special-
+   purpose character sets to signal that capability to a server which is
+   capable of representing documents in those character sets. The ISO-
+   8859-1 character set can be assumed to be acceptable to all user
+   agents.
+
+          Accept-Charset = "Accept-Charset" ":"
+                    1#( charset [ ";" "q" "=" qvalue ] )
+
+   Character set values are described in section 3.4. Each charset may
+   be given an associated quality value which represents the user's
+   preference for that charset. The default value is q=1. An example is
+
+          Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
+
+   If no Accept-Charset header is present, the default is that any
+   character set is acceptable. If an Accept-Charset header is present,
+   and if the server cannot send a response which is acceptable
+   according to the Accept-Charset header, then the server SHOULD send
+   an error response with the 406 (not acceptable) status code, though
+   the sending of an unacceptable response is also allowed.
+
+14.3 Accept-Encoding
+
+   The Accept-Encoding request-header field is similar to Accept, but
+   restricts the content-coding values (section 14.12) which are
+   acceptable in the response.
+
+          Accept-Encoding  = "Accept-Encoding" ":"
+                                    #( content-coding )
+
+   An example of its use is
+
+          Accept-Encoding: compress, gzip
+
+   If no Accept-Encoding header is present in a request, the server MAY
+   assume that the client will accept any content coding. If an Accept-
+   Encoding header is present, and if the server cannot send a response
+   which is acceptable according to the Accept-Encoding header, then the
+   server SHOULD send an error response with the 406 (Not Acceptable)
+   status code.
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 97]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   An empty Accept-Encoding value indicates none are acceptable.
+
+14.4 Accept-Language
+
+   The Accept-Language request-header field is similar to Accept, but
+   restricts the set of natural languages that are preferred as a
+   response to the request.
+
+          Accept-Language = "Accept-Language" ":"
+                            1#( language-range [ ";" "q" "=" qvalue ] )
+
+          language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
+
+   Each language-range MAY be given an associated quality value which
+   represents an estimate of the user's preference for the languages
+   specified by that range. The quality value defaults to "q=1". For
+   example,
+
+          Accept-Language: da, en-gb;q=0.8, en;q=0.7
+
+   would mean: "I prefer Danish, but will accept British English and
+   other types of English." A language-range matches a language-tag if
+   it exactly equals the tag, or if it exactly equals a prefix of the
+   tag such that the first tag character following the prefix is "-".
+   The special range "*", if present in the Accept-Language field,
+   matches every tag not matched by any other range present in the
+   Accept-Language field.
+
+     Note: This use of a prefix matching rule does not imply that
+     language tags are assigned to languages in such a way that it is
+     always true that if a user understands a language with a certain
+     tag, then this user will also understand all languages with tags
+     for which this tag is a prefix. The prefix rule simply allows the
+     use of prefix tags if this is the case.
+
+   The language quality factor assigned to a language-tag by the
+   Accept-Language field is the quality value of the longest language-
+   range in the field that matches the language-tag. If no language-
+   range in the field matches the tag, the language quality factor
+   assigned is 0. If no Accept-Language header is present in the
+   request, the server SHOULD assume that all languages are equally
+   acceptable. If an Accept-Language header is present, then all
+   languages which are assigned a quality factor greater than 0 are
+   acceptable.
+
+   It may be contrary to the privacy expectations of the user to send an
+   Accept-Language header with the complete linguistic preferences of
+   the user in every request. For a discussion of this issue, see
+
+
+
+Fielding, et. al.           Standards Track                    [Page 98]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   section 15.7.
+
+     Note: As intelligibility is highly dependent on the individual
+     user, it is recommended that client applications make the choice of
+     linguistic preference available to the user. If the choice is not
+     made available, then the Accept-Language header field must not be
+     given in the request.
+
+14.5 Accept-Ranges
+
+   The Accept-Ranges response-header field allows the server to indicate
+   its acceptance of range requests for a resource:
+
+          Accept-Ranges     = "Accept-Ranges" ":" acceptable-ranges
+
+          acceptable-ranges = 1#range-unit | "none"
+
+   Origin servers that accept byte-range requests MAY send
+
+          Accept-Ranges: bytes
+
+   but are not required to do so. Clients MAY generate byte-range
+   requests without having received this header for the resource
+   involved.
+
+   Servers that do not accept any kind of range request for a  resource
+   MAY send
+
+          Accept-Ranges: none
+
+   to advise the client not to attempt a range request.
+
+14.6 Age
+
+   The Age response-header field conveys the sender's estimate of the
+   amount of time since the response (or its revalidation) was generated
+   at the origin server. A cached response is "fresh" if its age does
+   not exceed its freshness lifetime. Age values are calculated as
+   specified in section 13.2.3.
+
+           Age = "Age" ":" age-value
+
+           age-value = delta-seconds
+
+   Age values are non-negative decimal integers, representing time in
+   seconds.
+
+
+
+
+
+Fielding, et. al.           Standards Track                    [Page 99]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   If a cache receives a value larger than the largest positive integer
+   it can represent, or if any of its age calculations overflows, it
+   MUST transmit an Age header with a value of 2147483648 (2^31).
+   HTTP/1.1 caches MUST send an Age header in every response. Caches
+   SHOULD use an arithmetic type of at least 31 bits of range.
+
+14.7 Allow
+
+   The Allow entity-header field lists the set of methods supported by
+   the resource identified by the Request-URI. The purpose of this field
+   is strictly to inform the recipient of valid methods associated with
+   the resource. An Allow header field MUST be present in a 405 (Method
+   Not Allowed) response.
+
+          Allow          = "Allow" ":" 1#method
+
+   Example of use:
+
+          Allow: GET, HEAD, PUT
+
+   This field cannot prevent a client from trying other methods.
+   However, the indications given by the Allow header field value SHOULD
+   be followed. The actual set of allowed methods is defined by the
+   origin server at the time of each request.
+
+   The Allow header field MAY be provided with a PUT request to
+   recommend the methods to be supported by the new or modified
+   resource. The server is not required to support these methods and
+   SHOULD include an Allow header in the response giving the actual
+   supported methods.
+
+   A proxy MUST NOT modify the Allow header field even if it does not
+   understand all the methods specified, since the user agent MAY have
+   other means of communicating with the origin server.
+
+   The Allow header field does not indicate what methods are implemented
+   at the server level. Servers MAY use the Public response-header field
+   (section 14.35) to describe what methods are implemented on the
+   server as a whole.
+
+14.8 Authorization
+
+   A user agent that wishes to authenticate itself with a server--
+   usually, but not necessarily, after receiving a 401 response--MAY do
+   so by including an Authorization request-header field with the
+   request. The Authorization field value consists of credentials
+   containing the authentication information of the user agent for the
+   realm of the resource being requested.
+
+
+
+Fielding, et. al.           Standards Track                   [Page 100]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+          Authorization  = "Authorization" ":" credentials
+
+   HTTP access authentication is described in section 11. If a request
+   is authenticated and a realm specified, the same credentials SHOULD
+   be valid for all other requests within this realm.
+
+   When a shared cache (see section 13.7) receives a request containing
+   an Authorization field, it MUST NOT return the corresponding response
+   as a reply to any other request, unless one of the following specific
+   exceptions holds:
+
+     1. If the response includes the "proxy-revalidate" Cache-Control
+        directive, the cache MAY use that response in replying to a
+        subsequent request, but a proxy cache MUST first revalidate it with
+        the origin server, using the request-headers from the new request
+        to allow the origin server to authenticate the new request.
+     2. If the response includes the "must-revalidate" Cache-Control
+        directive, the cache MAY use that response in replying to a
+        subsequent request, but all caches MUST first revalidate it with
+        the origin server, using the request-headers from the new request
+        to allow the origin server to authenticate the new request.
+     3. If the response includes the "public" Cache-Control directive, it
+        may be returned in reply to any subsequent request.
+
+14.9 Cache-Control
+
+   The Cache-Control general-header field is used to specify directives
+   that MUST be obeyed by all caching mechanisms along the
+   request/response chain. The directives specify behavior intended to
+   prevent caches from adversely interfering with the request or
+   response. These directives typically override the default caching
+   algorithms. Cache directives are unidirectional in that the presence
+   of a directive in a request does not imply that the same directive
+   should be given in the response.
+
+     Note that HTTP/1.0 caches may not implement Cache-Control and may
+     only implement Pragma: no-cache (see section 14.32).
+
+   Cache directives must be passed through by a proxy or gateway
+   application, regardless of their significance to that application,
+   since the directives may be applicable to all recipients along the
+   request/response chain. It is not possible to specify a cache-
+   directive for a specific cache.
+
+          Cache-Control   = "Cache-Control" ":" 1#cache-directive
+
+          cache-directive = cache-request-directive
+                          | cache-response-directive
+
+
+
+Fielding, et. al.           Standards Track                   [Page 101]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+          cache-request-directive =
+                            "no-cache" [ "=" <"> 1#field-name <"> ]
+                          | "no-store"
+                          | "max-age" "=" delta-seconds
+                          | "max-stale" [ "=" delta-seconds ]
+                          | "min-fresh" "=" delta-seconds
+                          | "only-if-cached"
+                          | cache-extension
+
+          cache-response-directive =
+                            "public"
+                          | "private" [ "=" <"> 1#field-name <"> ]
+                          | "no-cache" [ "=" <"> 1#field-name <"> ]
+                          | "no-store"
+                          | "no-transform"
+                          | "must-revalidate"
+                          | "proxy-revalidate"
+                          | "max-age" "=" delta-seconds
+                          | cache-extension
+
+          cache-extension = token [ "=" ( token | quoted-string ) ]
+
+   When a directive appears without any 1#field-name parameter, the
+   directive applies to the entire request or response. When such a
+   directive appears with a 1#field-name parameter, it applies only to
+   the named field or fields, and not to the rest of the request or
+   response.  This mechanism supports extensibility; implementations of
+   future versions of the HTTP protocol may apply these directives to
+   header fields not defined in HTTP/1.1.
+
+   The cache-control directives can be broken down into these general
+   categories:
+
+     o  Restrictions on what is cachable; these may only be imposed by the
+        origin server.
+     o  Restrictions on what may be stored by a cache; these may be imposed
+        by either the origin server or the user agent.
+     o  Modifications of the basic expiration mechanism; these may be
+        imposed by either the origin server or the user agent.
+     o  Controls over cache revalidation and reload; these may only be
+        imposed by a user agent.
+     o  Control over transformation of entities.
+     o  Extensions to the caching system.
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 102]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+14.9.1 What is Cachable
+
+   By default, a response is cachable if the requirements of the request
+   method, request header fields, and the response status indicate that
+   it is cachable. Section 13.4 summarizes these defaults for
+   cachability. The following Cache-Control response directives allow an
+   origin server to override the default cachability of a response:
+
+public
+  Indicates that the response is cachable by any cache, even if it
+  would normally be non-cachable or cachable only within a non-shared
+  cache. (See also Authorization, section 14.8, for additional
+  details.)
+
+private
+  Indicates that all or part of the response message is intended for a
+  single user and MUST NOT be cached by a shared cache. This allows an
+  origin server to state that the specified parts of the response are
+  intended for only one user and are not a valid response for requests
+  by other users. A private (non-shared) cache may cache the response.
+
+  Note: This usage of the word private only controls where the
+  response may be cached, and cannot ensure the privacy of the
+  message content.
+
+no-cache
+  Indicates that all or part of the response message MUST NOT be cached
+  anywhere. This allows an origin server to prevent caching even by
+  caches that have been configured to return stale responses to client
+  requests.
+
+  Note: Most HTTP/1.0 caches will not recognize or obey this
+  directive.
+
+14.9.2 What May be Stored by Caches
+
+   The purpose of the no-store directive is to prevent the inadvertent
+   release or retention of sensitive information (for example, on backup
+   tapes). The no-store directive applies to the entire message, and may
+   be sent either in a response or in a request. If sent in a request, a
+   cache MUST NOT store any part of either this request or any response
+   to it. If sent in a response, a cache MUST NOT store any part of
+   either this response or the request that elicited it. This directive
+   applies to both non-shared and shared caches. "MUST NOT store" in
+   this context means that the cache MUST NOT intentionally store the
+   information in non-volatile storage, and MUST make a best-effort
+   attempt to remove the information from volatile storage as promptly
+   as possible after forwarding it.
+
+
+
+Fielding, et. al.           Standards Track                   [Page 103]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Even when this directive is associated with a response, users may
+   explicitly store such a response outside of the caching system (e.g.,
+   with a "Save As" dialog). History buffers may store such responses as
+   part of their normal operation.
+
+   The purpose of this directive is to meet the stated requirements of
+   certain users and service authors who are concerned about accidental
+   releases of information via unanticipated accesses to cache data
+   structures. While the use of this directive may improve privacy in
+   some cases, we caution that it is NOT in any way a reliable or
+   sufficient mechanism for ensuring privacy. In particular, malicious
+   or compromised caches may not recognize or obey this directive; and
+   communications networks may be vulnerable to eavesdropping.
+
+14.9.3 Modifications of the Basic Expiration Mechanism
+
+   The expiration time of an entity may be specified by the origin
+   server using the Expires header (see section 14.21). Alternatively,
+   it may be specified using the max-age directive in a response.
+
+   If a response includes both an Expires header and a max-age
+   directive, the max-age directive overrides the Expires header, even
+   if the Expires header is more restrictive. This rule allows an origin
+   server to provide, for a given response, a longer expiration time to
+   an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This may be
+   useful if certain HTTP/1.0 caches improperly calculate ages or
+   expiration times, perhaps due to desynchronized clocks.
+
+     Note: most older caches, not compliant with this specification, do
+     not implement any Cache-Control directives.  An origin server
+     wishing to use a Cache-Control directive that restricts, but does
+     not prevent, caching by an HTTP/1.1-compliant cache may exploit the
+     requirement that the max-age directive overrides the Expires
+     header, and the fact that non-HTTP/1.1-compliant caches do not
+     observe the max-age directive.
+
+   Other directives allow an user agent to modify the basic expiration
+   mechanism. These directives may be specified on a request:
+
+   max-age
+     Indicates that the client is willing to accept a response whose age
+     is no greater than the specified time in seconds. Unless max-stale
+     directive is also included, the client is not willing to accept a
+     stale response.
+
+   min-fresh
+     Indicates that the client is willing to accept a response whose
+     freshness lifetime is no less than its current age plus the
+
+
+
+Fielding, et. al.           Standards Track                   [Page 104]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+     specified time in seconds. That is, the client wants a response
+     that will still be fresh for at least the specified number of
+     seconds.
+
+   max-stale
+     Indicates that the client is willing to accept a response that has
+     exceeded its expiration time. If max-stale is assigned a value,
+     then the client is willing to accept a response that has exceeded
+     its expiration time by no more than the specified number of
+     seconds. If no value is assigned to max-stale, then the client is
+     willing to accept a stale response of any age.
+
+   If a cache returns a stale response, either because of a max-stale
+   directive on a request, or because the cache is configured to
+   override the expiration time of a response, the cache MUST attach a
+   Warning header to the stale response, using Warning 10 (Response is
+   stale).
+
+14.9.4 Cache Revalidation and Reload Controls
+
+   Sometimes an user agent may want or need to insist that a cache
+   revalidate its cache entry with the origin server (and not just with
+   the next cache along the path to the origin server), or to reload its
+   cache entry from the origin server. End-to-end revalidation may be
+   necessary if either the cache or the origin server has overestimated
+   the expiration time of the cached response. End-to-end reload may be
+   necessary if the cache entry has become corrupted for some reason.
+
+   End-to-end revalidation may be requested either when the client does
+   not have its own local cached copy, in which case we call it
+   "unspecified end-to-end revalidation", or when the client does have a
+   local cached copy, in which case we call it "specific end-to-end
+   revalidation."
+
+   The client can specify these three kinds of action using Cache-
+   Control request directives:
+
+   End-to-end reload
+     The request includes a "no-cache" Cache-Control directive or, for
+     compatibility with HTTP/1.0 clients, "Pragma: no-cache". No field
+     names may be included with the no-cache directive in a request. The
+     server MUST NOT use a cached copy when responding to such a
+     request.
+
+   Specific end-to-end revalidation
+     The request includes a "max-age=0" Cache-Control directive, which
+     forces each cache along the path to the origin server to revalidate
+     its own entry, if any, with the next cache or server. The initial
+
+
+
+Fielding, et. al.           Standards Track                   [Page 105]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+     request includes a cache-validating conditional with the client's
+     current validator.
+
+   Unspecified end-to-end revalidation
+     The request includes "max-age=0" Cache-Control directive, which
+     forces each cache along the path to the origin server to revalidate
+     its own entry, if any, with the next cache or server. The initial
+     request does not include a cache-validating conditional; the first
+     cache along the path (if any) that holds a cache entry for this
+     resource includes a cache-validating conditional with its current
+     validator.
+
+   When an intermediate cache is forced, by means of a max-age=0
+   directive, to revalidate its own cache entry, and the client has
+   supplied its own validator in the request, the supplied validator may
+   differ from the validator currently stored with the cache entry. In
+   this case, the cache may use either validator in making its own
+   request without affecting semantic transparency.
+
+   However, the choice of validator may affect performance. The best
+   approach is for the intermediate cache to use its own validator when
+   making its request. If the server replies with 304 (Not Modified),
+   then the cache should return its now validated copy to the client
+   with a 200 (OK) response. If the server replies with a new entity and
+   cache validator, however, the intermediate cache should compare the
+   returned validator with the one provided in the client's request,
+   using the strong comparison function. If the client's validator is
+   equal to the origin server's, then the intermediate cache simply
+   returns 304 (Not Modified). Otherwise, it returns the new entity with
+   a 200 (OK) response.
+
+   If a request includes the no-cache directive, it should not include
+   min-fresh, max-stale, or max-age.
+
+   In some cases, such as times of extremely poor network connectivity,
+   a client may want a cache to return only those responses that it
+   currently has stored, and not to reload or revalidate with the origin
+   server. To do this, the client may include the only-if-cached
+   directive in a request. If it receives this directive, a cache SHOULD
+   either respond using a cached entry that is consistent with the other
+   constraints of the request, or respond with a 504 (Gateway Timeout)
+   status. However, if a group of caches is being operated as a unified
+   system with good internal connectivity, such a request MAY be
+   forwarded within that group of caches.
+
+   Because a cache may be configured to ignore a server's specified
+   expiration time, and because a client request may include a max-stale
+   directive (which has a similar effect), the protocol also includes a
+
+
+
+Fielding, et. al.           Standards Track                   [Page 106]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   mechanism for the origin server to require revalidation of a cache
+   entry on any subsequent use. When the must-revalidate directive is
+   present in a response received by a cache, that cache MUST NOT use
+   the entry after it becomes stale to respond to a subsequent request
+   without first revalidating it with the origin server. (I.e., the
+   cache must do an end-to-end revalidation every time, if, based solely
+   on the origin server's Expires or max-age value, the cached response
+   is stale.)
+
+   The must-revalidate directive is necessary to support reliable
+   operation for certain protocol features. In all circumstances an
+   HTTP/1.1 cache MUST obey the must-revalidate directive; in
+   particular, if the cache cannot reach the origin server for any
+   reason, it MUST generate a 504 (Gateway Timeout) response.
+
+   Servers should send the must-revalidate directive if and only if
+   failure to revalidate a request on the entity could result in
+   incorrect operation, such as a silently unexecuted financial
+   transaction.  Recipients MUST NOT take any automated action that
+   violates this directive, and MUST NOT automatically provide an
+   unvalidated copy of the entity if revalidation fails.
+
+   Although this is not recommended, user agents operating under severe
+   connectivity constraints may violate this directive but, if so, MUST
+   explicitly warn the user that an unvalidated response has been
+   provided.  The warning MUST be provided on each unvalidated access,
+   and SHOULD require explicit user confirmation.
+
+   The proxy-revalidate directive has the same meaning as the must-
+   revalidate directive, except that it does not apply to non-shared
+   user agent caches. It can be used on a response to an authenticated
+   request to permit the user's cache to store and later return the
+   response without needing to revalidate it (since it has already been
+   authenticated once by that user), while still requiring proxies that
+   service many users to revalidate each time (in order to make sure
+   that each user has been authenticated). Note that such authenticated
+   responses also need the public cache control directive in order to
+   allow them to be cached at all.
+
+14.9.5 No-Transform Directive
+
+   Implementers of intermediate caches (proxies) have found it useful to
+   convert the media type of certain entity bodies. A proxy might, for
+   example, convert between image formats in order to save cache space
+   or to reduce the amount of traffic on a slow link. HTTP has to date
+   been silent on these transformations.
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 107]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Serious operational problems have already occurred, however, when
+   these transformations have been applied to entity bodies intended for
+   certain kinds of applications. For example, applications for medical
+   imaging, scientific data analysis and those using end-to-end
+   authentication, all depend on receiving an entity body that is bit
+   for bit identical to the original entity-body.
+
+   Therefore, if a response includes the no-transform directive, an
+   intermediate cache or proxy MUST NOT change those headers that are
+   listed in section 13.5.2 as being subject to the no-transform
+   directive.  This implies that the cache or proxy must not change any
+   aspect of the entity-body that is specified by these headers.
+
+14.9.6 Cache Control Extensions
+
+   The Cache-Control header field can be extended through the use of one
+   or more cache-extension tokens, each with an optional assigned value.
+   Informational extensions (those which do not require a change in
+   cache behavior) may be added without changing the semantics of other
+   directives. Behavioral extensions are designed to work by acting as
+   modifiers to the existing base of cache directives. Both the new
+   directive and the standard directive are supplied, such that
+   applications which do not understand the new directive will default
+   to the behavior specified by the standard directive, and those that
+   understand the new directive will recognize it as modifying the
+   requirements associated with the standard directive.  In this way,
+   extensions to the Cache-Control directives can be made without
+   requiring changes to the base protocol.
+
+   This extension mechanism depends on a HTTP cache obeying all of the
+   cache-control directives defined for its native HTTP-version, obeying
+   certain extensions, and ignoring all directives that it does not
+   understand.
+
+   For example, consider a hypothetical new response directive called
+   "community" which acts as a modifier to the "private" directive. We
+   define this new directive to mean that, in addition to any non-shared
+   cache, any cache which is shared only by members of the community
+   named within its value may cache the response. An origin server
+   wishing to allow the "UCI" community to use an otherwise private
+   response in their shared cache(s) may do so by including
+
+          Cache-Control: private, community="UCI"
+
+   A cache seeing this header field will act correctly even if the cache
+   does not understand the "community" cache-extension, since it will
+   also see and understand the "private" directive and thus default to
+   the safe behavior.
+
+
+
+Fielding, et. al.           Standards Track                   [Page 108]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Unrecognized cache-directives MUST be ignored; it is assumed that any
+   cache-directive likely to be unrecognized by an HTTP/1.1 cache will
+   be combined with standard directives (or the response's default
+   cachability) such that the cache behavior will remain minimally
+   correct even if the cache does not understand the extension(s).
+
+14.10 Connection
+
+   The Connection general-header field allows the sender to specify
+   options that are desired for that particular connection and MUST NOT
+   be communicated by proxies over further connections.
+
+   The Connection header has the following grammar:
+
+          Connection-header = "Connection" ":" 1#(connection-token)
+          connection-token  = token
+
+   HTTP/1.1 proxies MUST parse the Connection header field before a
+   message is forwarded and, for each connection-token in this field,
+   remove any header field(s) from the message with the same name as the
+   connection-token. Connection options are signaled by the presence of
+   a connection-token in the Connection header field, not by any
+   corresponding additional header field(s), since the additional header
+   field may not be sent if there are no parameters associated with that
+   connection option.  HTTP/1.1 defines the "close" connection option
+   for the sender to signal that the connection will be closed after
+   completion of the response. For example,
+
+          Connection: close
+
+   in either the request or the response header fields indicates that
+   the connection should not be considered `persistent' (section 8.1)
+   after the current request/response is complete.
+
+   HTTP/1.1 applications that do not support persistent connections MUST
+   include the "close" connection option in every message.
+
+14.11 Content-Base
+
+   The Content-Base entity-header field may be used to specify the base
+   URI for resolving relative URLs within the entity. This header field
+   is described as Base in RFC 1808, which is expected to be revised.
+
+          Content-Base      = "Content-Base" ":" absoluteURI
+
+   If no Content-Base field is present, the base URI of an entity is
+   defined either by its Content-Location (if that Content-Location URI
+   is an absolute URI) or the URI used to initiate the request, in that
+
+
+
+Fielding, et. al.           Standards Track                   [Page 109]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   order of precedence. Note, however, that the base URI of the contents
+   within the entity-body may be redefined within that entity-body.
+
+14.12 Content-Encoding
+
+   The Content-Encoding entity-header field is used as a modifier to the
+   media-type. When present, its value indicates what additional content
+   codings have been applied to the entity-body, and thus what decoding
+   mechanisms MUST be applied in order to obtain the media-type
+   referenced by the Content-Type header field. Content-Encoding is
+   primarily used to allow a document to be compressed without losing
+   the identity of its underlying media type.
+
+          Content-Encoding  = "Content-Encoding" ":" 1#content-coding
+
+   Content codings are defined in section 3.5. An example of its use is
+
+          Content-Encoding: gzip
+
+   The Content-Encoding is a characteristic of the entity identified by
+   the Request-URI. Typically, the entity-body is stored with this
+   encoding and is only decoded before rendering or analogous usage.
+
+   If multiple encodings have been applied to an entity, the content
+   codings MUST be listed in the order in which they were applied.
+
+   Additional information about the encoding parameters MAY be provided
+   by other entity-header fields not defined by this specification.
+
+14.13 Content-Language
+
+   The Content-Language entity-header field describes the natural
+   language(s) of the intended audience for the enclosed entity. Note
+   that this may not be equivalent to all the languages used within the
+   entity-body.
+
+          Content-Language  = "Content-Language" ":" 1#language-tag
+
+   Language tags are defined in section 3.10. The primary purpose of
+   Content-Language is to allow a user to identify and differentiate
+   entities according to the user's own preferred language. Thus, if the
+   body content is intended only for a Danish-literate audience, the
+   appropriate field is
+
+          Content-Language: da
+
+   If no Content-Language is specified, the default is that the content
+   is intended for all language audiences. This may mean that the sender
+
+
+
+Fielding, et. al.           Standards Track                   [Page 110]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   does not consider it to be specific to any natural language, or that
+   the sender does not know for which language it is intended.
+
+   Multiple languages MAY be listed for content that is intended for
+   multiple audiences. For example, a rendition of the "Treaty of
+   Waitangi," presented simultaneously in the original Maori and English
+   versions, would call for
+
+          Content-Language: mi, en
+
+   However, just because multiple languages are present within an entity
+   does not mean that it is intended for multiple linguistic audiences.
+   An example would be a beginner's language primer, such as "A First
+   Lesson in Latin," which is clearly intended to be used by an
+   English-literate audience. In this case, the Content-Language should
+   only include "en".
+
+   Content-Language may be applied to any media type -- it is not
+   limited to textual documents.
+
+14.14 Content-Length
+
+   The Content-Length entity-header field indicates the size of the
+   message-body, in decimal number of octets, sent to the recipient or,
+   in the case of the HEAD method, the size of the entity-body that
+   would have been sent had the request been a GET.
+
+          Content-Length    = "Content-Length" ":" 1*DIGIT
+
+   An example is
+
+          Content-Length: 3495
+
+   Applications SHOULD use this field to indicate the size of the
+   message-body to be transferred, regardless of the media type of the
+   entity. It must be possible for the recipient to reliably determine
+   the end of HTTP/1.1 requests containing an entity-body, e.g., because
+   the request has a valid Content-Length field, uses Transfer-Encoding:
+   chunked or a multipart body.
+
+   Any Content-Length greater than or equal to zero is a valid value.
+   Section 4.4 describes how to determine the length of a message-body
+   if a Content-Length is not given.
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 111]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+     Note: The meaning of this field is significantly different from the
+     corresponding definition in MIME, where it is an optional field
+     used within the "message/external-body" content-type. In HTTP, it
+     SHOULD be sent whenever the message's length can be determined
+     prior to being transferred.
+
+14.15 Content-Location
+
+   The Content-Location entity-header field may be used to supply the
+   resource location for the entity enclosed in the message. In the case
+   where a resource has multiple entities associated with it, and those
+   entities actually have separate locations by which they might be
+   individually accessed, the server should provide a Content-Location
+   for the particular variant which is returned. In addition, a server
+   SHOULD provide a Content-Location for the resource corresponding to
+   the response entity.
+
+          Content-Location = "Content-Location" ":"
+                            ( absoluteURI | relativeURI )
+
+   If no Content-Base header field is present, the value of Content-
+   Location also defines the base URL for the entity (see section
+   14.11).
+
+   The Content-Location value is not a replacement for the original
+   requested URI; it is only a statement of the location of the resource
+   corresponding to this particular entity at the time of the request.
+   Future requests MAY use the Content-Location URI if the desire is to
+   identify the source of that particular entity.
+
+   A cache cannot assume that an entity with a Content-Location
+   different from the URI used to retrieve it can be used to respond to
+   later requests on that Content-Location URI. However, the Content-
+   Location can be used to differentiate between multiple entities
+   retrieved from a single requested resource, as described in section
+   13.6.
+
+   If the Content-Location is a relative URI, the URI is interpreted
+   relative to any Content-Base URI provided in the response. If no
+   Content-Base is provided, the relative URI is interpreted relative to
+   the Request-URI.
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 112]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+14.16 Content-MD5
+
+   The Content-MD5 entity-header field, as defined in RFC 1864 [23], is
+   an MD5 digest of the entity-body for the purpose of providing an
+   end-to-end message integrity check (MIC) of the entity-body. (Note: a
+   MIC is good for detecting accidental modification of the entity-body
+   in transit, but is not proof against malicious attacks.)
+
+           Content-MD5   = "Content-MD5" ":" md5-digest
+
+           md5-digest   = <base64 of 128 bit MD5 digest as per RFC 1864>
+
+   The Content-MD5 header field may be generated by an origin server to
+   function as an integrity check of the entity-body. Only origin
+   servers may generate the Content-MD5 header field; proxies and
+   gateways MUST NOT generate it, as this would defeat its value as an
+   end-to-end integrity check. Any recipient of the entity-body,
+   including gateways and proxies, MAY check that the digest value in
+   this header field matches that of the entity-body as received.
+
+   The MD5 digest is computed based on the content of the entity-body,
+   including any Content-Encoding that has been applied, but not
+   including any Transfer-Encoding that may have been applied to the
+   message-body. If the message is received with a Transfer-Encoding,
+   that encoding must be removed prior to checking the Content-MD5 value
+   against the received entity.
+
+   This has the result that the digest is computed on the octets of the
+   entity-body exactly as, and in the order that, they would be sent if
+   no Transfer-Encoding were being applied.
+
+   HTTP extends RFC 1864 to permit the digest to be computed for MIME
+   composite media-types (e.g., multipart/* and message/rfc822), but
+   this does not change how the digest is computed as defined in the
+   preceding paragraph.
+
+     Note: There are several consequences of this. The entity-body for
+     composite types may contain many body-parts, each with its own MIME
+     and HTTP headers (including Content-MD5, Content-Transfer-Encoding,
+     and Content-Encoding headers). If a body-part has a Content-
+     Transfer-Encoding or Content-Encoding header, it is assumed that
+     the content of the body-part has had the encoding applied, and the
+     body-part is included in the Content-MD5 digest as is -- i.e.,
+     after the application. The Transfer-Encoding header field is not
+     allowed within body-parts.
+
+     Note: while the definition of Content-MD5 is exactly the same for
+     HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
+
+
+
+Fielding, et. al.           Standards Track                   [Page 113]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+     in which the application of Content-MD5 to HTTP entity-bodies
+     differs from its application to MIME entity-bodies. One is that
+     HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does
+     use Transfer-Encoding and Content-Encoding. Another is that HTTP
+     more frequently uses binary content types than MIME, so it is worth
+     noting that, in such cases, the byte order used to compute the
+     digest is the transmission byte order defined for the type. Lastly,
+     HTTP allows transmission of text types with any of several line
+     break conventions and not just the canonical form using CRLF.
+     Conversion of all line breaks to CRLF should not be done before
+     computing or checking the digest: the line break convention used in
+     the text actually transmitted should be left unaltered when
+     computing the digest.
+
+14.17 Content-Range
+
+   The Content-Range entity-header is sent with a partial entity-body to
+   specify where in the full entity-body the partial body should be
+   inserted. It also indicates the total size of the full entity-body.
+   When a server returns a partial response to a client, it must
+   describe both the extent of the range covered by the response, and
+   the length of the entire entity-body.
+
+          Content-Range = "Content-Range" ":" content-range-spec
+
+          content-range-spec      = byte-content-range-spec
+
+          byte-content-range-spec = bytes-unit SP first-byte-pos "-"
+                                    last-byte-pos "/" entity-length
+
+          entity-length           = 1*DIGIT
+
+   Unlike byte-ranges-specifier values, a byte-content-range-spec may
+   only specify one range, and must contain absolute byte positions for
+   both the first and last byte of the range.
+
+   A byte-content-range-spec whose last-byte-pos value is less than its
+   first-byte-pos value, or whose entity-length value is less than or
+   equal to its last-byte-pos value, is invalid. The recipient of an
+   invalid byte-content-range-spec MUST ignore it and any content
+   transferred along with it.
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 114]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Examples of byte-content-range-spec values, assuming that the entity
+   contains a total of 1234 bytes:
+
+     o  The first 500 bytes:
+
+          bytes 0-499/1234
+
+     o  The second 500 bytes:
+
+          bytes 500-999/1234
+
+     o  All except for the first 500 bytes:
+
+          bytes 500-1233/1234
+
+     o  The last 500 bytes:
+
+          bytes 734-1233/1234
+
+   When an HTTP message includes the content of a single range (for
+   example, a response to a request for a single range, or to a request
+   for a set of ranges that overlap without any holes), this content is
+   transmitted with a Content-Range header, and a Content-Length header
+   showing the number of bytes actually transferred. For example,
+
+          HTTP/1.1 206 Partial content
+          Date: Wed, 15 Nov 1995 06:25:24 GMT
+          Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
+          Content-Range: bytes 21010-47021/47022
+          Content-Length: 26012
+          Content-Type: image/gif
+
+   When an HTTP message includes the content of multiple ranges (for
+   example, a response to a request for multiple non-overlapping
+   ranges), these are transmitted as a multipart MIME message. The
+   multipart MIME content-type used for this purpose is defined in this
+   specification to be "multipart/byteranges". See appendix 19.2 for its
+   definition.
+
+   A client that cannot decode a MIME multipart/byteranges message
+   should not ask for multiple byte-ranges in a single request.
+
+   When a client requests multiple byte-ranges in one request, the
+   server SHOULD return them in the order that they appeared in the
+   request.
+
+   If the server ignores a byte-range-spec because it is invalid, the
+   server should treat the request as if the invalid Range header field
+
+
+
+Fielding, et. al.           Standards Track                   [Page 115]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   did not exist. (Normally, this means return a 200 response containing
+   the full entity). The reason is that the only time a client will make
+   such an invalid request is when the entity is smaller than the entity
+   retrieved by a prior request.
+
+14.18 Content-Type
+
+   The Content-Type entity-header field indicates the media type of the
+   entity-body sent to the recipient or, in the case of the HEAD method,
+   the media type that would have been sent had the request been a GET.
+
+          Content-Type   = "Content-Type" ":" media-type
+   Media types are defined in section 3.7. An example of the field is
+
+          Content-Type: text/html; charset=ISO-8859-4
+
+   Further discussion of methods for identifying the media type of an
+   entity is provided in section 7.2.1.
+
+14.19 Date
+
+   The Date general-header field represents the date and time at which
+   the message was originated, having the same semantics as orig-date in
+   RFC 822. The field value is an HTTP-date, as described in section
+   3.3.1.
+
+          Date  = "Date" ":" HTTP-date
+
+   An example is
+
+          Date: Tue, 15 Nov 1994 08:12:31 GMT
+
+   If a message is received via direct connection with the user agent
+   (in the case of requests) or the origin server (in the case of
+   responses), then the date can be assumed to be the current date at
+   the receiving end. However, since the date--as it is believed by the
+   origin--is important for evaluating cached responses, origin servers
+   MUST include a Date header field in all responses. Clients SHOULD
+   only send a Date header field in messages that include an entity-
+   body, as in the case of the PUT and POST requests, and even then it
+   is optional. A received message which does not have a Date header
+   field SHOULD be assigned one by the recipient if the message will be
+   cached by that recipient or gatewayed via a protocol which requires a
+   Date.
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 116]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   In theory, the date SHOULD represent the moment just before the
+   entity is generated. In practice, the date can be generated at any
+   time during the message origination without affecting its semantic
+   value.
+
+   The format of the Date is an absolute date and time as defined by
+   HTTP-date in section 3.3; it MUST be sent in RFC1123 [8]-date format.
+
+14.20 ETag
+
+   The ETag entity-header field defines the entity tag for the
+   associated entity. The headers used with entity tags are described in
+   sections 14.20, 14.25, 14.26 and 14.43. The entity tag may be used
+   for comparison with other entities from the same resource (see
+   section 13.3.2).
+
+         ETag = "ETag" ":" entity-tag
+
+   Examples:
+
+         ETag: "xyzzy"
+         ETag: W/"xyzzy"
+         ETag: ""
+
+14.21 Expires
+
+   The Expires entity-header field gives the date/time after which the
+   response should be considered stale. A stale cache entry may not
+   normally be returned by a cache (either a proxy cache or an user
+   agent cache) unless it is first validated with the origin server (or
+   with an intermediate cache that has a fresh copy of the entity). See
+   section 13.2 for further discussion of the expiration model.
+
+   The presence of an Expires field does not imply that the original
+   resource will change or cease to exist at, before, or after that
+   time.
+
+   The format is an absolute date and time as defined by HTTP-date in
+   section 3.3; it MUST be in RFC1123-date format:
+
+         Expires = "Expires" ":" HTTP-date
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 117]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   An example of its use is
+
+         Expires: Thu, 01 Dec 1994 16:00:00 GMT
+
+     Note: if a response includes a Cache-Control field with the max-age
+     directive, that directive overrides the Expires field.
+
+   HTTP/1.1 clients and caches MUST treat other invalid date formats,
+   especially including the value "0", as in the past (i.e., "already
+   expired").
+
+   To mark a response as "already expired," an origin server should use
+   an Expires date that is equal to the Date header value. (See the
+   rules for expiration calculations in section 13.2.4.)
+
+   To mark a response as "never expires," an origin server should use an
+   Expires date approximately one year from the time the response is
+   sent.  HTTP/1.1 servers should not send Expires dates more than one
+   year in the future.
+
+   The presence of an Expires header field with a date value of some
+   time in the future on an response that otherwise would by default be
+   non-cacheable indicates that the response is cachable, unless
+   indicated otherwise by a Cache-Control header field (section 14.9).
+
+14.22 From
+
+   The From request-header field, if given, SHOULD contain an Internet
+   e-mail address for the human user who controls the requesting user
+   agent.  The address SHOULD be machine-usable, as defined by mailbox
+   in RFC 822 (as updated by RFC 1123 ):
+
+          From   = "From" ":" mailbox
+
+   An example is:
+
+          From: [e-mail]
+
+   This header field MAY be used for logging purposes and as a means for
+   identifying the source of invalid or unwanted requests. It SHOULD NOT
+   be used as an insecure form of access protection. The interpretation
+   of this field is that the request is being performed on behalf of the
+   person given, who accepts responsibility for the method performed. In
+   particular, robot agents SHOULD include this header so that the
+   person responsible for running the robot can be contacted if problems
+   occur on the receiving end.
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 118]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   The Internet e-mail address in this field MAY be separate from the
+   Internet host which issued the request. For example, when a request
+   is passed through a proxy the original issuer's address SHOULD be
+   used.
+
+     Note: The client SHOULD not send the From header field without the
+     user's approval, as it may conflict with the user's privacy
+     interests or their site's security policy. It is strongly
+     recommended that the user be able to disable, enable, and modify
+     the value of this field at any time prior to a request.
+
+14.23 Host
+
+   The Host request-header field specifies the Internet host and port
+   number of the resource being requested, as obtained from the original
+   URL given by the user or referring resource (generally an HTTP URL,
+   as described in section 3.2.2). The Host field value MUST represent
+   the network location of the origin server or gateway given by the
+   original URL. This allows the origin server or gateway to
+   differentiate between internally-ambiguous URLs, such as the root "/"
+   URL of a server for multiple host names on a single IP address.
+
+          Host = "Host" ":" host [ ":" port ]    ; Section 3.2.2
+
+   A "host" without any trailing port information implies the default
+   port for the service requested (e.g., "80" for an HTTP URL). For
+   example, a request on the origin server for
+   <http://www.w3.org/pub/WWW/> MUST include:
+
+          GET /pub/WWW/ HTTP/1.1
+          Host: www.w3.org
+
+   A client MUST include a Host header field in all HTTP/1.1 request
+   messages on the Internet (i.e., on any message corresponding to a
+   request for a URL which includes an Internet host address for the
+   service being requested). If the Host field is not already present,
+   an HTTP/1.1 proxy MUST add a Host field to the request message prior
+   to forwarding it on the Internet. All Internet-based HTTP/1.1 servers
+   MUST respond with a 400 status code to any HTTP/1.1 request message
+   which lacks a Host header field.
+
+   See sections 5.2 and 19.5.1 for other requirements relating to Host.
+
+14.24 If-Modified-Since
+
+   The If-Modified-Since request-header field is used with the GET
+   method to make it conditional: if the requested variant has not been
+   modified since the time specified in this field, an entity will not
+
+
+
+Fielding, et. al.           Standards Track                   [Page 119]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   be returned from the server; instead, a 304 (not modified) response
+   will be returned without any message-body.
+
+          If-Modified-Since = "If-Modified-Since" ":" HTTP-date
+
+   An example of the field is:
+
+          If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
+
+   A GET method with an If-Modified-Since header and no Range header
+   requests that the identified entity be transferred only if it has
+   been modified since the date given by the If-Modified-Since header.
+   The algorithm for determining this includes the following cases:
+
+   a)If the request would normally result in anything other than a 200
+     (OK) status, or if the passed If-Modified-Since date is invalid, the
+     response is exactly the same as for a normal GET. A date which is
+     later than the server's current time is invalid.
+
+   b)If the variant has been modified since the If-Modified-Since date,
+     the response is exactly the same as for a normal GET.
+
+   c)If the variant has not been modified since a valid If-Modified-Since
+     date, the server MUST return a 304 (Not Modified) response.
+
+   The purpose of this feature is to allow efficient updates of cached
+   information with a minimum amount of transaction overhead.
+
+     Note that the Range request-header field modifies the meaning of
+     If-Modified-Since; see section 14.36 for full details.
+
+     Note that If-Modified-Since times are interpreted by the server,
+     whose clock may not be synchronized with the client.
+
+   Note that if a client uses an arbitrary date in the If-Modified-Since
+   header instead of a date taken from the Last-Modified header for the
+   same request, the client should be aware of the fact that this date
+   is interpreted in the server's understanding of time. The client
+   should consider unsynchronized clocks and rounding problems due to
+   the different encodings of time between the client and server. This
+   includes the possibility of race conditions if the document has
+   changed between the time it was first requested and the If-Modified-
+   Since date of a subsequent request, and the possibility of clock-
+   skew-related problems if the If-Modified-Since date is derived from
+   the client's clock without correction to the server's clock.
+   Corrections for different time bases between client and server are at
+   best approximate due to network latency.
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 120]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+14.25 If-Match
+
+   The If-Match request-header field is used with a method to make it
+   conditional. A client that has one or more entities previously
+   obtained from the resource can verify that one of those entities is
+   current by including a list of their associated entity tags in the
+   If-Match header field. The purpose of this feature is to allow
+   efficient updates of cached information with a minimum amount of
+   transaction overhead. It is also used, on updating requests, to
+   prevent inadvertent modification of the wrong version of a resource.
+   As a special case, the value "*" matches any current entity of the
+   resource.
+
+          If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
+
+   If any of the entity tags match the entity tag of the entity that
+   would have been returned in the response to a similar GET request
+   (without the If-Match header) on that resource, or if "*" is given
+   and any current entity exists for that resource, then the server MAY
+   perform the requested method as if the If-Match header field did not
+   exist.
+
+   A server MUST use the strong comparison function (see section 3.11)
+   to compare the entity tags in If-Match.
+
+   If none of the entity tags match, or if "*" is given and no current
+   entity exists, the server MUST NOT perform the requested method, and
+   MUST return a 412 (Precondition Failed) response. This behavior is
+   most useful when the client wants to prevent an updating method, such
+   as PUT, from modifying a resource that has changed since the client
+   last retrieved it.
+
+   If the request would, without the If-Match header field, result in
+   anything other than a 2xx status, then the If-Match header MUST be
+   ignored.
+
+   The meaning of "If-Match: *" is that the method SHOULD be performed
+   if the representation selected by the origin server (or by a cache,
+   possibly using the Vary mechanism, see section 14.43) exists, and
+   MUST NOT be performed if the representation does not exist.
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 121]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   A request intended to update a resource (e.g., a PUT) MAY include an
+   If-Match header field to signal that the request method MUST NOT be
+   applied if the entity corresponding to the If-Match value (a single
+   entity tag) is no longer a representation of that resource.  This
+   allows the user to indicate that they do not wish the request to be
+   successful if the resource has been changed without their knowledge.
+   Examples:
+
+          If-Match: "xyzzy"
+          If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
+          If-Match: *
+
+14.26 If-None-Match
+
+   The If-None-Match request-header field is used with a method to make
+   it conditional. A client that has one or more entities previously
+   obtained from the resource can verify that none of those entities is
+   current by including a list of their associated entity tags in the
+   If-None-Match header field. The purpose of this feature is to allow
+   efficient updates of cached information with a minimum amount of
+   transaction overhead. It is also used, on updating requests, to
+   prevent inadvertent modification of a resource which was not known to
+   exist.
+
+   As a special case, the value "*" matches any current entity of the
+   resource.
+
+          If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
+
+   If any of the entity tags match the entity tag of the entity that
+   would have been returned in the response to a similar GET request
+   (without the If-None-Match header) on that resource, or if "*" is
+   given and any current entity exists for that resource, then the
+   server MUST NOT perform the requested method. Instead, if the request
+   method was GET or HEAD, the server SHOULD respond with a 304 (Not
+   Modified) response, including the cache-related entity-header fields
+   (particularly ETag) of one of the entities that matched. For all
+   other request methods, the server MUST respond with a status of 412
+   (Precondition Failed).
+
+   See section 13.3.3 for rules on how to determine if two entity tags
+   match. The weak comparison function can only be used with GET or HEAD
+   requests.
+
+   If none of the entity tags match, or if "*" is given and no current
+   entity exists, then the server MAY perform the requested method as if
+   the If-None-Match header field did not exist.
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 122]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   If the request would, without the If-None-Match header field, result
+   in anything other than a 2xx status, then the If-None-Match header
+   MUST be ignored.
+
+   The meaning of "If-None-Match: *" is that the method MUST NOT be
+   performed if the representation selected by the origin server (or by
+   a cache, possibly using the Vary mechanism, see section 14.43)
+   exists, and SHOULD be performed if the representation does not exist.
+   This feature may be useful in preventing races between PUT
+   operations.
+
+   Examples:
+
+          If-None-Match: "xyzzy"
+          If-None-Match: W/"xyzzy"
+          If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
+          If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
+          If-None-Match: *
+
+14.27 If-Range
+
+   If a client has a partial copy of an entity in its cache, and wishes
+   to have an up-to-date copy of the entire entity in its cache, it
+   could use the Range request-header with a conditional GET (using
+   either or both of If-Unmodified-Since and If-Match.) However, if the
+   condition fails because the entity has been modified, the client
+   would then have to make a second request to obtain the entire current
+   entity-body.
+
+   The If-Range header allows a client to "short-circuit" the second
+   request. Informally, its meaning is `if the entity is unchanged, send
+   me the part(s) that I am missing; otherwise, send me the entire new
+   entity.'
+
+           If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
+
+   If the client has no entity tag for an entity, but does have a Last-
+   Modified date, it may use that date in a If-Range header. (The server
+   can distinguish between a valid HTTP-date and any form of entity-tag
+   by examining no more than two characters.) The If-Range header should
+   only be used together with a Range header, and must be ignored if the
+   request does not include a Range header, or if the server does not
+   support the sub-range operation.
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 123]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   If the entity tag given in the If-Range header matches the current
+   entity tag for the entity, then the server should provide the
+   specified sub-range of the entity using a 206 (Partial content)
+   response. If the entity tag does not match, then the server should
+   return the entire entity using a 200 (OK) response.
+
+14.28 If-Unmodified-Since
+
+   The If-Unmodified-Since request-header field is used with a method to
+   make it conditional. If the requested resource has not been modified
+   since the time specified in this field, the server should perform the
+   requested operation as if the If-Unmodified-Since header were not
+   present.
+
+   If the requested variant has been modified since the specified time,
+   the server MUST NOT perform the requested operation, and MUST return
+   a 412 (Precondition Failed).
+
+         If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
+
+   An example of the field is:
+
+          If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
+
+   If the request normally (i.e., without the If-Unmodified-Since
+   header) would result in anything other than a 2xx status, the If-
+   Unmodified-Since header should be ignored.
+
+   If the specified date is invalid, the header is ignored.
+
+14.29 Last-Modified
+
+   The Last-Modified entity-header field indicates the date and time at
+   which the origin server believes the variant was last modified.
+
+          Last-Modified  = "Last-Modified" ":" HTTP-date
+
+   An example of its use is
+
+          Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
+
+   The exact meaning of this header field depends on the implementation
+   of the origin server and the nature of the original resource. For
+   files, it may be just the file system last-modified time. For
+   entities with dynamically included parts, it may be the most recent
+   of the set of last-modify times for its component parts. For database
+   gateways, it may be the last-update time stamp of the record. For
+   virtual objects, it may be the last time the internal state changed.
+
+
+
+Fielding, et. al.           Standards Track                   [Page 124]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   An origin server MUST NOT send a Last-Modified date which is later
+   than the server's time of message origination. In such cases, where
+   the resource's last modification would indicate some time in the
+   future, the server MUST replace that date with the message
+   origination date.
+
+   An origin server should obtain the Last-Modified value of the entity
+   as close as possible to the time that it generates the Date value of
+   its response. This allows a recipient to make an accurate assessment
+   of the entity's modification time, especially if the entity changes
+   near the time that the response is generated.
+
+   HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
+
+14.30 Location
+
+   The Location response-header field is used to redirect the recipient
+   to a location other than the Request-URI for completion of the
+   request or identification of a new resource. For 201 (Created)
+   responses, the Location is that of the new resource which was created
+   by the request.  For 3xx responses, the location SHOULD indicate the
+   server's preferred URL for automatic redirection to the resource. The
+   field value consists of a single absolute URL.
+
+          Location       = "Location" ":" absoluteURI
+
+   An example is
+
+          Location: http://www.w3.org/pub/WWW/People.html
+
+     Note: The Content-Location header field (section 14.15) differs
+     from Location in that the Content-Location identifies the original
+     location of the entity enclosed in the request. It is therefore
+     possible for a response to contain header fields for both Location
+     and Content-Location. Also see section 13.10 for cache requirements
+     of some methods.
+
+14.31 Max-Forwards
+
+   The Max-Forwards request-header field may be used with the TRACE
+   method (section 14.31) to limit the number of proxies or gateways
+   that can forward the request to the next inbound server. This can be
+   useful when the client is attempting to trace a request chain which
+   appears to be failing or looping in mid-chain.
+
+          Max-Forwards   = "Max-Forwards" ":" 1*DIGIT
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 125]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   The Max-Forwards value is a decimal integer indicating the remaining
+   number of times this request message may be forwarded.
+
+   Each proxy or gateway recipient of a TRACE request containing a Max-
+   Forwards header field SHOULD check and update its value prior to
+   forwarding the request. If the received value is zero (0), the
+   recipient SHOULD NOT forward the request; instead, it SHOULD respond
+   as the final recipient with a 200 (OK) response containing the
+   received request message as the response entity-body (as described in
+   section 9.8). If the received Max-Forwards value is greater than
+   zero, then the forwarded message SHOULD contain an updated Max-
+   Forwards field with a value decremented by one (1).
+
+   The Max-Forwards header field SHOULD be ignored for all other methods
+   defined by this specification and for any extension methods for which
+   it is not explicitly referred to as part of that method definition.
+
+14.32 Pragma
+
+   The Pragma general-header field is used to include implementation-
+   specific directives that may apply to any recipient along the
+   request/response chain. All pragma directives specify optional
+   behavior from the viewpoint of the protocol; however, some systems
+   MAY require that behavior be consistent with the directives.
+
+          Pragma            = "Pragma" ":" 1#pragma-directive
+
+          pragma-directive  = "no-cache" | extension-pragma
+          extension-pragma  = token [ "=" ( token | quoted-string ) ]
+
+   When the no-cache directive is present in a request message, an
+   application SHOULD forward the request toward the origin server even
+   if it has a cached copy of what is being requested. This pragma
+   directive has the same semantics as the no-cache cache-directive (see
+   section 14.9) and is defined here for backwards compatibility with
+   HTTP/1.0.  Clients SHOULD include both header fields when a no-cache
+   request is sent to a server not known to be HTTP/1.1 compliant.
+
+   Pragma directives MUST be passed through by a proxy or gateway
+   application, regardless of their significance to that application,
+   since the directives may be applicable to all recipients along the
+   request/response chain. It is not possible to specify a pragma for a
+   specific recipient; however, any pragma directive not relevant to a
+   recipient SHOULD be ignored by that recipient.
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 126]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   HTTP/1.1 clients SHOULD NOT send the Pragma request-header. HTTP/1.1
+   caches SHOULD treat "Pragma: no-cache" as if the client had sent
+   "Cache-Control: no-cache". No new Pragma directives will be defined
+   in HTTP.
+
+14.33 Proxy-Authenticate
+
+   The Proxy-Authenticate response-header field MUST be included as part
+   of a 407 (Proxy Authentication Required) response. The field value
+   consists of a challenge that indicates the authentication scheme and
+   parameters applicable to the proxy for this Request-URI.
+
+          Proxy-Authenticate  = "Proxy-Authenticate" ":" challenge
+
+   The HTTP access authentication process is described in section 11.
+   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
+   only to the current connection and SHOULD NOT be passed on to
+   downstream clients. However, an intermediate proxy may need to obtain
+   its own credentials by requesting them from the downstream client,
+   which in some circumstances will appear as if the proxy is forwarding
+   the Proxy-Authenticate header field.
+
+14.34 Proxy-Authorization
+
+   The Proxy-Authorization request-header field allows the client to
+   identify itself (or its user) to a proxy which requires
+   authentication.  The Proxy-Authorization field value consists of
+   credentials containing the authentication information of the user
+   agent for the proxy and/or realm of the resource being requested.
+
+       Proxy-Authorization     = "Proxy-Authorization" ":" credentials
+
+   The HTTP access authentication process is described in section 11.
+   Unlike Authorization, the Proxy-Authorization header field applies
+   only to the next outbound proxy that demanded authentication using
+   the Proxy-Authenticate field. When multiple proxies are used in a
+   chain, the Proxy-Authorization header field is consumed by the first
+   outbound proxy that was expecting to receive credentials. A proxy MAY
+   relay the credentials from the client request to the next proxy if
+   that is the mechanism by which the proxies cooperatively authenticate
+   a given request.
+
+14.35 Public
+
+   The Public response-header field lists the set of methods supported
+   by the server. The purpose of this field is strictly to inform the
+   recipient of the capabilities of the server regarding unusual
+   methods.  The methods listed may or may not be applicable to the
+
+
+
+Fielding, et. al.           Standards Track                   [Page 127]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Request-URI; the Allow header field (section 14.7) MAY be used to
+   indicate methods allowed for a particular URI.
+
+          Public         = "Public" ":" 1#method
+
+   Example of use:
+
+          Public: OPTIONS, MGET, MHEAD, GET, HEAD
+
+   This header field applies only to the server directly connected to
+   the client (i.e., the nearest neighbor in a chain of connections). If
+   the response passes through a proxy, the proxy MUST either remove the
+   Public header field or replace it with one applicable to its own
+   capabilities.
+
+14.36 Range
+
+14.36.1 Byte Ranges
+
+   Since all HTTP entities are represented in HTTP messages as sequences
+   of bytes, the concept of a byte range is meaningful for any HTTP
+   entity.  (However, not all clients and servers need to support byte-
+   range operations.)
+
+   Byte range specifications in HTTP apply to the sequence of bytes in
+   the entity-body (not necessarily the same as the message-body).
+
+   A byte range operation may specify a single range of bytes, or a set
+   of ranges within a single entity.
+
+       ranges-specifier = byte-ranges-specifier
+
+       byte-ranges-specifier = bytes-unit "=" byte-range-set
+
+       byte-range-set  = 1#( byte-range-spec | suffix-byte-range-spec )
+
+       byte-range-spec = first-byte-pos "-" [last-byte-pos]
+
+       first-byte-pos  = 1*DIGIT
+
+       last-byte-pos   = 1*DIGIT
+
+   The first-byte-pos value in a byte-range-spec gives the byte-offset
+   of the first byte in a range. The last-byte-pos value gives the
+   byte-offset of the last byte in the range; that is, the byte
+   positions specified are inclusive. Byte offsets start at zero.
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 128]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   If the last-byte-pos value is present, it must be greater than or
+   equal to the first-byte-pos in that byte-range-spec, or the byte-
+   range-spec is invalid. The recipient of an invalid byte-range-spec
+   must ignore it.
+
+   If the last-byte-pos value is absent, or if the value is greater than
+   or equal to the current length of the entity-body, last-byte-pos is
+   taken to be equal to one less than the current length of the entity-
+   body in bytes.
+
+   By its choice of last-byte-pos, a client can limit the number of
+   bytes retrieved without knowing the size of the entity.
+
+          suffix-byte-range-spec = "-" suffix-length
+
+          suffix-length = 1*DIGIT
+
+   A suffix-byte-range-spec is used to specify the suffix of the
+   entity-body, of a length given by the suffix-length value. (That is,
+   this form specifies the last N bytes of an entity-body.) If the
+   entity is shorter than the specified suffix-length, the entire
+   entity-body is used.
+
+   Examples of byte-ranges-specifier values (assuming an entity-body of
+   length 10000):
+
+     o  The first 500 bytes (byte offsets 0-499, inclusive):
+
+          bytes=0-499
+
+     o  The second 500 bytes (byte offsets 500-999, inclusive):
+
+          bytes=500-999
+
+     o  The final 500 bytes (byte offsets 9500-9999, inclusive):
+
+          bytes=-500
+
+     o  Or
+
+          bytes=9500-
+
+     o  The first and last bytes only (bytes 0 and 9999):
+
+          bytes=0-0,-1
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 129]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+     o  Several legal but not canonical specifications of the second
+        500 bytes (byte offsets 500-999, inclusive):
+
+          bytes=500-600,601-999
+
+          bytes=500-700,601-999
+
+14.36.2 Range Retrieval Requests
+
+   HTTP retrieval requests using conditional or unconditional GET
+   methods may request one or more sub-ranges of the entity, instead of
+   the entire entity, using the Range request header, which applies to
+   the entity returned as the result of the request:
+
+         Range = "Range" ":" ranges-specifier
+
+   A server MAY ignore the Range header. However, HTTP/1.1 origin
+   servers and intermediate caches SHOULD support byte ranges when
+   possible, since Range supports efficient recovery from partially
+   failed transfers, and supports efficient partial retrieval of large
+   entities.
+
+   If the server supports the Range header and the specified range or
+   ranges are appropriate for the entity:
+
+     o  The presence of a Range header in an unconditional GET modifies
+        what is returned if the GET is otherwise successful. In other
+        words, the response carries a status code of 206 (Partial
+        Content) instead of 200 (OK).
+
+     o  The presence of a Range header in a conditional GET (a request
+        using one or both of If-Modified-Since and If-None-Match, or
+        one or both of If-Unmodified-Since and If-Match) modifies what
+        is returned if the GET is otherwise successful and the condition
+        is true. It does not affect the 304 (Not Modified) response
+        returned if the conditional is false.
+
+   In some cases, it may be more appropriate to use the If-Range header
+   (see section 14.27) in addition to the Range header.
+
+   If a proxy that supports ranges receives a Range request, forwards
+   the request to an inbound server, and receives an entire entity in
+   reply, it SHOULD only return the requested range to its client. It
+   SHOULD store the entire received response in its cache, if that is
+   consistent with its cache allocation policies.
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 130]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+14.37 Referer
+
+   The Referer[sic] request-header field allows the client to specify,
+   for the server's benefit, the address (URI) of the resource from
+   which the Request-URI was obtained (the "referrer", although the
+   header field is misspelled.) The Referer request-header allows a
+   server to generate lists of back-links to resources for interest,
+   logging, optimized caching, etc. It also allows obsolete or mistyped
+   links to be traced for maintenance. The Referer field MUST NOT be
+   sent if the Request-URI was obtained from a source that does not have
+   its own URI, such as input from the user keyboard.
+
+        Referer        = "Referer" ":" ( absoluteURI | relativeURI )
+
+   Example:
+
+        Referer: http://www.w3.org/hypertext/DataSources/Overview.html
+
+   If the field value is a partial URI, it SHOULD be interpreted
+   relative to the Request-URI. The URI MUST NOT include a fragment.
+
+     Note: Because the source of a link may be private information or
+     may reveal an otherwise private information source, it is strongly
+     recommended that the user be able to select whether or not the
+     Referer field is sent. For example, a browser client could have a
+     toggle switch for browsing openly/anonymously, which would
+     respectively enable/disable the sending of Referer and From
+     information.
+
+14.38 Retry-After
+
+   The Retry-After response-header field can be used with a 503 (Service
+   Unavailable) response to indicate how long the service is expected to
+   be unavailable to the requesting client. The value of this field can
+   be either an HTTP-date or an integer number of seconds (in decimal)
+   after the time of the response.
+
+          Retry-After  = "Retry-After" ":" ( HTTP-date | delta-seconds )
+
+   Two examples of its use are
+
+          Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
+          Retry-After: 120
+
+   In the latter example, the delay is 2 minutes.
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 131]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+14.39 Server
+
+   The Server response-header field contains information about the
+   software used by the origin server to handle the request. The field
+   can contain multiple product tokens (section 3.8) and comments
+   identifying the server and any significant subproducts. The product
+   tokens are listed in order of their significance for identifying the
+   application.
+
+          Server         = "Server" ":" 1*( product | comment )
+
+   Example:
+
+          Server: CERN/3.0 libwww/2.17
+
+   If the response is being forwarded through a proxy, the proxy
+   application MUST NOT modify the Server response-header. Instead, it
+   SHOULD include a Via field (as described in section 14.44).
+
+     Note: Revealing the specific software version of the server may
+     allow the server machine to become more vulnerable to attacks
+     against software that is known to contain security holes. Server
+     implementers are encouraged to make this field a configurable
+     option.
+
+14.40 Transfer-Encoding
+
+   The Transfer-Encoding general-header field indicates what (if any)
+   type of transformation has been applied to the message body in order
+   to safely transfer it between the sender and the recipient. This
+   differs from the Content-Encoding in that the transfer coding is a
+   property of the message, not of the entity.
+
+          Transfer-Encoding       = "Transfer-Encoding" ":" 1#transfer-
+   coding
+
+   Transfer codings are defined in section 3.6. An example is:
+
+          Transfer-Encoding: chunked
+
+   Many older HTTP/1.0 applications do not understand the Transfer-
+   Encoding header.
+
+14.41 Upgrade
+
+   The Upgrade general-header allows the client to specify what
+   additional communication protocols it supports and would like to use
+   if the server finds it appropriate to switch protocols. The server
+
+
+
+Fielding, et. al.           Standards Track                   [Page 132]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   MUST use the Upgrade header field within a 101 (Switching Protocols)
+   response to indicate which protocol(s) are being switched.
+
+          Upgrade        = "Upgrade" ":" 1#product
+
+   For example,
+
+          Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
+
+   The Upgrade header field is intended to provide a simple mechanism
+   for transition from HTTP/1.1 to some other, incompatible protocol. It
+   does so by allowing the client to advertise its desire to use another
+   protocol, such as a later version of HTTP with a higher major version
+   number, even though the current request has been made using HTTP/1.1.
+   This eases the difficult transition between incompatible protocols by
+   allowing the client to initiate a request in the more commonly
+   supported protocol while indicating to the server that it would like
+   to use a "better" protocol if available (where "better" is determined
+   by the server, possibly according to the nature of the method and/or
+   resource being requested).
+
+   The Upgrade header field only applies to switching application-layer
+   protocols upon the existing transport-layer connection. Upgrade
+   cannot be used to insist on a protocol change; its acceptance and use
+   by the server is optional. The capabilities and nature of the
+   application-layer communication after the protocol change is entirely
+   dependent upon the new protocol chosen, although the first action
+   after changing the protocol MUST be a response to the initial HTTP
+   request containing the Upgrade header field.
+
+   The Upgrade header field only applies to the immediate connection.
+   Therefore, the upgrade keyword MUST be supplied within a Connection
+   header field (section 14.10) whenever Upgrade is present in an
+   HTTP/1.1 message.
+
+   The Upgrade header field cannot be used to indicate a switch to a
+   protocol on a different connection. For that purpose, it is more
+   appropriate to use a 301, 302, 303, or 305 redirection response.
+
+   This specification only defines the protocol name "HTTP" for use by
+   the family of Hypertext Transfer Protocols, as defined by the HTTP
+   version rules of section 3.1 and future updates to this
+   specification. Any token can be used as a protocol name; however, it
+   will only be useful if both the client and server associate the name
+   with the same protocol.
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 133]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+14.42 User-Agent
+
+   The User-Agent request-header field contains information about the
+   user agent originating the request. This is for statistical purposes,
+   the tracing of protocol violations, and automated recognition of user
+   agents for the sake of tailoring responses to avoid particular user
+   agent limitations. User agents SHOULD include this field with
+   requests. The field can contain multiple product tokens (section 3.8)
+   and comments identifying the agent and any subproducts which form a
+   significant part of the user agent. By convention, the product tokens
+   are listed in order of their significance for identifying the
+   application.
+
+          User-Agent     = "User-Agent" ":" 1*( product | comment )
+
+   Example:
+
+          User-Agent: CERN-LineMode/2.15 libwww/2.17b3
+
+14.43 Vary
+
+   The Vary response-header field is used by a server to signal that the
+   response entity was selected from the available representations of
+   the response using server-driven negotiation (section 12). Field-
+   names listed in Vary headers are those of request-headers. The Vary
+   field value indicates either that the given set of header fields
+   encompass the dimensions over which the representation might vary, or
+   that the dimensions of variance are unspecified ("*") and thus may
+   vary over any aspect of future requests.
+
+          Vary  = "Vary" ":" ( "*" | 1#field-name )
+
+   An HTTP/1.1 server MUST include an appropriate Vary header field with
+   any cachable response that is subject to server-driven negotiation.
+   Doing so allows a cache to properly interpret future requests on that
+   resource and informs the user agent about the presence of negotiation
+   on that resource. A server SHOULD include an appropriate Vary header
+   field with a non-cachable response that is subject to server-driven
+   negotiation, since this might provide the user agent with useful
+   information about the dimensions over which the response might vary.
+
+   The set of header fields named by the Vary field value is known as
+   the "selecting" request-headers.
+
+   When the cache receives a subsequent request whose Request-URI
+   specifies one or more cache entries including a Vary header, the
+   cache MUST NOT use such a cache entry to construct a response to the
+   new request unless all of the headers named in the cached Vary header
+
+
+
+Fielding, et. al.           Standards Track                   [Page 134]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   are present in the new request, and all of the stored selecting
+   request-headers from the previous request match the corresponding
+   headers in the new request.
+
+   The selecting request-headers from two requests are defined to match
+   if and only if the selecting request-headers in the first request can
+   be transformed to the selecting request-headers in the second request
+   by adding or removing linear whitespace (LWS) at places where this is
+   allowed by the corresponding BNF, and/or combining multiple message-
+   header fields with the same field name following the rules about
+   message headers in section 4.2.
+
+   A Vary field value of "*" signals that unspecified parameters,
+   possibly other than the contents of request-header fields (e.g., the
+   network address of the client), play a role in the selection of the
+   response representation. Subsequent requests on that resource can
+   only be properly interpreted by the origin server, and thus a cache
+   MUST forward a (possibly conditional) request even when it has a
+   fresh response cached for the resource. See section 13.6 for use of
+   the Vary header by caches.
+
+   A Vary field value consisting of a list of field-names signals that
+   the representation selected for the response is based on a selection
+   algorithm which considers ONLY the listed request-header field values
+   in selecting the most appropriate representation. A cache MAY assume
+   that the same selection will be made for future requests with the
+   same values for the listed field names, for the duration of time in
+   which the response is fresh.
+
+   The field-names given are not limited to the set of standard
+   request-header fields defined by this specification. Field names are
+   case-insensitive.
+
+14.44 Via
+
+   The Via general-header field MUST be used by gateways and proxies to
+   indicate the intermediate protocols and recipients between the user
+   agent and the server on requests, and between the origin server and
+   the client on responses. It is analogous to the "Received" field of
+   RFC 822 and is intended to be used for tracking message forwards,
+   avoiding request loops, and identifying the protocol capabilities of
+   all senders along the request/response chain.
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 135]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+      Via =  "Via" ":" 1#( received-protocol received-by [ comment ] )
+
+      received-protocol = [ protocol-name "/" ] protocol-version
+      protocol-name     = token
+      protocol-version  = token
+      received-by       = ( host [ ":" port ] ) | pseudonym
+      pseudonym         = token
+
+   The received-protocol indicates the protocol version of the message
+   received by the server or client along each segment of the
+   request/response chain. The received-protocol version is appended to
+   the Via field value when the message is forwarded so that information
+   about the protocol capabilities of upstream applications remains
+   visible to all recipients.
+
+   The protocol-name is optional if and only if it would be "HTTP". The
+   received-by field is normally the host and optional port number of a
+   recipient server or client that subsequently forwarded the message.
+   However, if the real host is considered to be sensitive information,
+   it MAY be replaced by a pseudonym. If the port is not given, it MAY
+   be assumed to be the default port of the received-protocol.
+
+   Multiple Via field values represent each proxy or gateway that has
+   forwarded the message. Each recipient MUST append its information
+   such that the end result is ordered according to the sequence of
+   forwarding applications.
+
+   Comments MAY be used in the Via header field to identify the software
+   of the recipient proxy or gateway, analogous to the User-Agent and
+   Server header fields. However, all comments in the Via field are
+   optional and MAY be removed by any recipient prior to forwarding the
+   message.
+
+   For example, a request message could be sent from an HTTP/1.0 user
+   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
+   forward the request to a public proxy at nowhere.com, which completes
+   the request by forwarding it to the origin server at www.ics.uci.edu.
+   The request received by www.ics.uci.edu would then have the following
+   Via header field:
+
+          Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
+
+   Proxies and gateways used as a portal through a network firewall
+   SHOULD NOT, by default, forward the names and ports of hosts within
+   the firewall region. This information SHOULD only be propagated if
+   explicitly enabled. If not enabled, the received-by host of any host
+   behind the firewall SHOULD be replaced by an appropriate pseudonym
+   for that host.
+
+
+
+Fielding, et. al.           Standards Track                   [Page 136]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   For organizations that have strong privacy requirements for hiding
+   internal structures, a proxy MAY combine an ordered subsequence of
+   Via header field entries with identical received-protocol values into
+   a single such entry. For example,
+
+          Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
+
+           could be collapsed to
+
+          Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
+
+   Applications SHOULD NOT combine multiple entries unless they are all
+   under the same organizational control and the hosts have already been
+   replaced by pseudonyms. Applications MUST NOT combine entries which
+   have different received-protocol values.
+
+14.45 Warning
+
+   The Warning response-header field is used to carry additional
+   information about the status of a response which may not be reflected
+   by the response status code. This information is typically, though
+   not exclusively, used to warn about a possible lack of semantic
+   transparency from caching operations.
+
+   Warning headers are sent with responses using:
+
+          Warning    = "Warning" ":" 1#warning-value
+
+          warning-value = warn-code SP warn-agent SP warn-text
+          warn-code  = 2DIGIT
+          warn-agent = ( host [ ":" port ] ) | pseudonym
+                          ; the name or pseudonym of the server adding
+                          ; the Warning header, for use in debugging
+          warn-text  = quoted-string
+
+   A response may carry more than one Warning header.
+
+   The warn-text should be in a natural language and character set that
+   is most likely to be intelligible to the human user receiving the
+   response.  This decision may be based on any available knowledge,
+   such as the location of the cache or user, the Accept-Language field
+   in a request, the Content-Language field in a response, etc. The
+   default language is English and the default character set is ISO-
+   8859-1.
+
+   If a character set other than ISO-8859-1 is used, it MUST be encoded
+   in the warn-text using the method described in RFC 1522 [14].
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 137]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Any server or cache may add Warning headers to a response. New
+   Warning headers should be added after any existing Warning headers. A
+   cache MUST NOT delete any Warning header that it received with a
+   response. However, if a cache successfully validates a cache entry,
+   it SHOULD remove any Warning headers previously attached to that
+   entry except as specified for specific Warning codes. It MUST then
+   add any Warning headers received in the validating response. In other
+   words, Warning headers are those that would be attached to the most
+   recent relevant response.
+
+   When multiple Warning headers are attached to a response, the user
+   agent SHOULD display as many of them as possible, in the order that
+   they appear in the response. If it is not possible to display all of
+   the warnings, the user agent should follow these heuristics:
+
+     o  Warnings that appear early in the response take priority over those
+        appearing later in the response.
+     o  Warnings in the user's preferred character set take priority over
+        warnings in other character sets but with identical warn-codes and
+        warn-agents.
+
+   Systems that generate multiple Warning headers should order them with
+   this user agent behavior in mind.
+
+   This is a list of the currently-defined warn-codes, each with a
+   recommended warn-text in English, and a description of its meaning.
+
+10 Response is stale
+  MUST be included whenever the returned response is stale. A cache may
+  add this warning to any response, but may never remove it until the
+  response is known to be fresh.
+
+11 Revalidation failed
+  MUST be included if a cache returns a stale response because an
+  attempt to revalidate the response failed, due to an inability to
+  reach the server. A cache may add this warning to any response, but
+  may never remove it until the response is successfully revalidated.
+
+12 Disconnected operation
+   SHOULD be included if the cache is intentionally disconnected from
+  the rest of the network for a period of time.
+
+13 Heuristic expiration
+  MUST be included if the cache heuristically chose a freshness
+  lifetime greater than 24 hours and the response's age is greater than
+  24 hours.
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 138]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+14 Transformation applied
+  MUST be added by an intermediate cache or proxy if it applies any
+  transformation changing the content-coding (as specified in the
+  Content-Encoding header) or media-type (as specified in the
+  Content-Type header) of the response, unless this Warning code
+  already appears in the response. MUST NOT be deleted from a response
+  even after revalidation.
+
+99 Miscellaneous warning
+  The warning text may include arbitrary information to be presented to
+  a human user, or logged. A system receiving this warning MUST NOT
+  take any automated action.
+
+14.46 WWW-Authenticate
+
+   The WWW-Authenticate response-header field MUST be included in 401
+   (Unauthorized) response messages. The field value consists of at
+   least one challenge that indicates the authentication scheme(s) and
+   parameters applicable to the Request-URI.
+
+          WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge
+
+   The HTTP access authentication process is described in section 11.
+   User agents MUST take special care in parsing the WWW-Authenticate
+   field value if it contains more than one challenge, or if more than
+   one WWW-Authenticate header field is provided, since the contents of
+   a challenge may itself contain a comma-separated list of
+   authentication parameters.
+
+15 Security Considerations
+
+   This section is meant to inform application developers, information
+   providers, and users of the security limitations in HTTP/1.1 as
+   described by this document. The discussion does not include
+   definitive solutions to the problems revealed, though it does make
+   some suggestions for reducing security risks.
+
+15.1 Authentication of Clients
+
+   The Basic authentication scheme is not a secure method of user
+   authentication, nor does it in any way protect the entity, which is
+   transmitted in clear text across the physical network used as the
+   carrier. HTTP does not prevent additional authentication schemes and
+   encryption mechanisms from being employed to increase security or the
+   addition of enhancements (such as schemes to use one-time passwords)
+   to Basic authentication.
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 139]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   The most serious flaw in Basic authentication is that it results in
+   the essentially clear text transmission of the user's password over
+   the physical network. It is this problem which Digest Authentication
+   attempts to address.
+
+   Because Basic authentication involves the clear text transmission of
+   passwords it SHOULD never be used (without enhancements) to protect
+   sensitive or valuable information.
+
+   A common use of Basic authentication is for identification purposes
+   -- requiring the user to provide a user name and password as a means
+   of identification, for example, for purposes of gathering accurate
+   usage statistics on a server. When used in this way it is tempting to
+   think that there is no danger in its use if illicit access to the
+   protected documents is not a major concern. This is only correct if
+   the server issues both user name and password to the users and in
+   particular does not allow the user to choose his or her own password.
+   The danger arises because naive users frequently reuse a single
+   password to avoid the task of maintaining multiple passwords.
+
+   If a server permits users to select their own passwords, then the
+   threat is not only illicit access to documents on the server but also
+   illicit access to the accounts of all users who have chosen to use
+   their account password. If users are allowed to choose their own
+   password that also means the server must maintain files containing
+   the (presumably encrypted) passwords. Many of these may be the
+   account passwords of users perhaps at distant sites. The owner or
+   administrator of such a system could conceivably incur liability if
+   this information is not maintained in a secure fashion.
+
+   Basic Authentication is also vulnerable to spoofing by counterfeit
+   servers. If a user can be led to believe that he is connecting to a
+   host containing information protected by basic authentication when in
+   fact he is connecting to a hostile server or gateway then the
+   attacker can request a password, store it for later use, and feign an
+   error. This type of attack is not possible with Digest Authentication
+   [32]. Server implementers SHOULD guard against the possibility of
+   this sort of counterfeiting by gateways or CGI scripts. In particular
+   it is very dangerous for a server to simply turn over a connection to
+   a gateway since that gateway can then use the persistent connection
+   mechanism to engage in multiple transactions with the client while
+   impersonating the original server in a way that is not detectable by
+   the client.
+
+15.2 Offering a Choice of Authentication Schemes
+
+   An HTTP/1.1 server may return multiple challenges with a 401
+   (Authenticate) response, and each challenge may use a different
+
+
+
+Fielding, et. al.           Standards Track                   [Page 140]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   scheme.  The order of the challenges returned to the user agent is in
+   the order that the server would prefer they be chosen. The server
+   should order its challenges with the "most secure" authentication
+   scheme first. A user agent should choose as the challenge to be made
+   to the user the first one that the user agent understands.
+
+   When the server offers choices of authentication schemes using the
+   WWW-Authenticate header, the "security" of the authentication is only
+   as malicious user could capture the set of challenges and try to
+   authenticate him/herself using the weakest of the authentication
+   schemes. Thus, the ordering serves more to protect the user's
+   credentials than the server's information.
+
+   A possible man-in-the-middle (MITM) attack would be to add a weak
+   authentication scheme to the set of choices, hoping that the client
+   will use one that exposes the user's credentials (e.g. password). For
+   this reason, the client should always use the strongest scheme that
+   it understands from the choices accepted.
+
+   An even better MITM attack would be to remove all offered choices,
+   and to insert a challenge that requests Basic authentication. For
+   this reason, user agents that are concerned about this kind of attack
+   could remember the strongest authentication scheme ever requested by
+   a server and produce a warning message that requires user
+   confirmation before using a weaker one. A particularly insidious way
+   to mount such a MITM attack would be to offer a "free" proxy caching
+   service to gullible users.
+
+15.3 Abuse of Server Log Information
+
+   A server is in the position to save personal data about a user's
+   requests which may identify their reading patterns or subjects of
+   interest. This information is clearly confidential in nature and its
+   handling may be constrained by law in certain countries. People using
+   the HTTP protocol to provide data are responsible for ensuring that
+   such material is not distributed without the permission of any
+   individuals that are identifiable by the published results.
+
+15.4 Transfer of Sensitive Information
+
+   Like any generic data transfer protocol, HTTP cannot regulate the
+   content of the data that is transferred, nor is there any a priori
+   method of determining the sensitivity of any particular piece of
+   information within the context of any given request. Therefore,
+   applications SHOULD supply as much control over this information as
+   possible to the provider of that information. Four header fields are
+   worth special mention in this context: Server, Via, Referer and From.
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 141]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Revealing the specific software version of the server may allow the
+   server machine to become more vulnerable to attacks against software
+   that is known to contain security holes. Implementers SHOULD make the
+   Server header field a configurable option.
+
+   Proxies which serve as a portal through a network firewall SHOULD
+   take special precautions regarding the transfer of header information
+   that identifies the hosts behind the firewall. In particular, they
+   SHOULD remove, or replace with sanitized versions, any Via fields
+   generated behind the firewall.
+
+   The Referer field allows reading patterns to be studied and reverse
+   links drawn. Although it can be very useful, its power can be abused
+   if user details are not separated from the information contained in
+   the Referer. Even when the personal information has been removed, the
+   Referer field may indicate a private document's URI whose publication
+   would be inappropriate.
+
+   The information sent in the From field might conflict with the user's
+   privacy interests or their site's security policy, and hence it
+   SHOULD NOT be transmitted without the user being able to disable,
+   enable, and modify the contents of the field. The user MUST be able
+   to set the contents of this field within a user preference or
+   application defaults configuration.
+
+   We suggest, though do not require, that a convenient toggle interface
+   be provided for the user to enable or disable the sending of From and
+   Referer information.
+
+15.5 Attacks Based On File and Path Names
+
+   Implementations of HTTP origin servers SHOULD be careful to restrict
+   the documents returned by HTTP requests to be only those that were
+   intended by the server administrators. If an HTTP server translates
+   HTTP URIs directly into file system calls, the server MUST take
+   special care not to serve files that were not intended to be
+   delivered to HTTP clients.  For example, UNIX, Microsoft Windows, and
+   other operating systems use ".." as a path component to indicate a
+   directory level above the current one. On such a system, an HTTP
+   server MUST disallow any such construct in the Request-URI if it
+   would otherwise allow access to a resource outside those intended to
+   be accessible via the HTTP server. Similarly, files intended for
+   reference only internally to the server (such as access control
+   files, configuration files, and script code) MUST be protected from
+   inappropriate retrieval, since they might contain sensitive
+   information. Experience has shown that minor bugs in such HTTP server
+   implementations have turned into security risks.
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 142]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+15.6 Personal Information
+
+   HTTP clients are often privy to large amounts of personal information
+   (e.g. the user's name, location, mail address, passwords, encryption
+   keys, etc.), and SHOULD be very careful to prevent unintentional
+   leakage of this information via the HTTP protocol to other sources.
+   We very strongly recommend that a convenient interface be provided
+   for the user to control dissemination of such information, and that
+   designers and implementers be particularly careful in this area.
+   History shows that errors in this area are often both serious
+   security and/or privacy problems, and often generate highly adverse
+   publicity for the implementer's company.
+
+15.7 Privacy Issues Connected to Accept Headers
+
+   Accept request-headers can reveal information about the user to all
+   servers which are accessed. The Accept-Language header in particular
+   can reveal information the user would consider to be of a private
+   nature, because the understanding of particular languages is often
+   strongly correlated to the membership of a particular ethnic group.
+   User agents which offer the option to configure the contents of an
+   Accept-Language header to be sent in every request are strongly
+   encouraged to let the configuration process include a message which
+   makes the user aware of the loss of privacy involved.
+
+   An approach that limits the loss of privacy would be for a user agent
+   to omit the sending of Accept-Language headers by default, and to ask
+   the user whether it should start sending Accept-Language headers to a
+   server if it detects, by looking for any Vary response-header fields
+   generated by the server, that such sending could improve the quality
+   of service.
+
+   Elaborate user-customized accept header fields sent in every request,
+   in particular if these include quality values, can be used by servers
+   as relatively reliable and long-lived user identifiers. Such user
+   identifiers would allow content providers to do click-trail tracking,
+   and would allow collaborating content providers to match cross-server
+   click-trails or form submissions of individual users. Note that for
+   many users not behind a proxy, the network address of the host
+   running the user agent will also serve as a long-lived user
+   identifier. In environments where proxies are used to enhance
+   privacy, user agents should be conservative in offering accept header
+   configuration options to end users. As an extreme privacy measure,
+   proxies could filter the accept headers in relayed requests. General
+   purpose user agents which provide a high degree of header
+   configurability should warn users about the loss of privacy which can
+   be involved.
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 143]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+15.8 DNS Spoofing
+
+   Clients using HTTP rely heavily on the Domain Name Service, and are
+   thus generally prone to security attacks based on the deliberate
+   mis-association of IP addresses and DNS names. Clients need to be
+   cautious in assuming the continuing validity of an IP number/DNS name
+   association.
+
+   In particular, HTTP clients SHOULD rely on their name resolver for
+   confirmation of an IP number/DNS name association, rather than
+   caching the result of previous host name lookups. Many platforms
+   already can cache host name lookups locally when appropriate, and
+   they SHOULD be configured to do so. These lookups should be cached,
+   however, only when the TTL (Time To Live) information reported by the
+   name server makes it likely that the cached information will remain
+   useful.
+
+   If HTTP clients cache the results of host name lookups in order to
+   achieve a performance improvement, they MUST observe the TTL
+   information reported by DNS.
+
+   If HTTP clients do not observe this rule, they could be spoofed when
+   a previously-accessed server's IP address changes. As network
+   renumbering is expected to become increasingly common, the
+   possibility of this form of attack will grow. Observing this
+   requirement thus reduces this potential security vulnerability.
+
+   This requirement also improves the load-balancing behavior of clients
+   for replicated servers using the same DNS name and reduces the
+   likelihood of a user's experiencing failure in accessing sites which
+   use that strategy.
+
+15.9 Location Headers and Spoofing
+
+   If a single server supports multiple organizations that do not trust
+   one another, then it must check the values of Location and Content-
+   Location headers in responses that are generated under control of
+   said organizations to make sure that they do not attempt to
+   invalidate resources over which they have no authority.
+
+16 Acknowledgments
+
+   This specification makes heavy use of the augmented BNF and generic
+   constructs defined by David H. Crocker for RFC 822. Similarly, it
+   reuses many of the definitions provided by Nathaniel Borenstein and
+   Ned Freed for MIME. We hope that their inclusion in this
+   specification will help reduce past confusion over the relationship
+   between HTTP and Internet mail message formats.
+
+
+
+Fielding, et. al.           Standards Track                   [Page 144]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   The HTTP protocol has evolved considerably over the past four years.
+   It has benefited from a large and active developer community--the
+   many people who have participated on the www-talk mailing list--and
+   it is that community which has been most responsible for the success
+   of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
+   Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois
+   Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob
+   McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc
+   VanHeyningen deserve special recognition for their efforts in
+   defining early aspects of the protocol.
+
+   This document has benefited greatly from the comments of all those
+   participating in the HTTP-WG. In addition to those already mentioned,
+   the following individuals have contributed to this specification:
+
+          Gary Adams                  Albert Lunde
+          Harald Tveit Alvestrand     John C. Mallery
+          Keith Ball                  Jean-Philippe Martin-Flatin
+          Brian Behlendorf            Larry Masinter
+          Paul Burchard               Mitra
+          Maurizio Codogno            David Morris
+          Mike Cowlishaw              Gavin Nicol
+          Roman Czyborra              Bill Perry
+          Michael A. Dolan            Jeffrey Perry
+          David J. Fiander            Scott Powers
+          Alan Freier                 Owen Rees
+          Marc Hedlund                Luigi Rizzo
+          Greg Herlihy                David Robinson
+          Koen Holtman                Marc Salomon
+          Alex Hopmann                Rich Salz
+          Bob Jernigan                Allan M. Schiffman
+          Shel Kaphan                 Jim Seidman
+          Rohit Khare                 Chuck Shotton
+          John Klensin                Eric W. Sink
+          Martijn Koster              Simon E. Spero
+          Alexei Kosut                Richard N. Taylor
+          David M. Kristol            Robert S. Thau
+          Daniel LaLiberte            Bill (BearHeart) Weinman
+          Ben Laurie                  Francois Yergeau
+          Paul J. Leach               Mary Ellen Zurko
+          Daniel DuBois
+
+   Much of the content and presentation of the caching design is due to
+   suggestions and comments from individuals including: Shel Kaphan,
+   Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 145]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   Most of the specification of ranges is based on work originally done
+   by Ari Luotonen and John Franks, with additional input from Steve
+   Zilles.
+
+   Thanks to the "cave men" of Palo Alto. You know who you are.
+
+   Jim Gettys (the current editor of this document) wishes particularly
+   to thank Roy Fielding, the previous editor of this document, along
+   with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen
+   Holtman, John Franks, Alex Hopmann, and Larry Masinter for their
+   help.
+
+17 References
+
+   [1] Alvestrand, H., "Tags for the identification of languages", RFC
+   1766, UNINETT, March 1995.
+
+   [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
+   D., and B. Alberti. "The Internet Gopher Protocol: (a distributed
+   document search and retrieval protocol)", RFC 1436, University of
+   Minnesota, March 1993.
+
+   [3] 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.
+
+   [4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource
+   Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota,
+   December 1994.
+
+   [5] Berners-Lee, T., and D. Connolly, "HyperText Markup Language
+   Specification - 2.0", RFC 1866, MIT/LCS, November 1995.
+
+   [6] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
+   Transfer Protocol -- HTTP/1.0.", RFC 1945 MIT/LCS, UC Irvine, May
+   1996.
+
+   [7] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
+   Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
+   2045, Innosoft, First Virtual, November 1996.
+
+   [8] Braden, R., "Requirements for Internet hosts - application and
+   support", STD 3,  RFC 1123, IETF, October 1989.
+
+   [9] Crocker, D., "Standard for the Format of ARPA Internet Text
+   Messages", STD 11, RFC 822, UDEL, August 1982.
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 146]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
+   Sui, J., and M. Grinbaum. "WAIS Interface Protocol Prototype
+   Functional Specification", (v1.5), Thinking Machines Corporation,
+   April 1990.
+
+   [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, UC
+   Irvine, June 1995.
+
+   [12] Horton, M., and R. Adams. "Standard for interchange of USENET
+   messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic
+   Studies, December 1987.
+
+   [13] Kantor, B., and P. Lapsley. "Network News Transfer Protocol." A
+   Proposed Standard for the Stream-Based Transmission of News", RFC
+   977, UC San Diego, UC Berkeley, February 1986.
+
+   [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
+   Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
+   University of Tennessee, November 1996.
+
+   [15] Nebel, E., and L. Masinter. "Form-based File Upload in HTML",
+   RFC 1867, Xerox Corporation, November 1995.
+
+   [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+   USC/ISI, August 1982.
+
+   [17] Postel, J., "Media Type Registration Procedure", RFC 2048,
+   USC/ISI, November 1996.
+
+   [18] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD
+   9, RFC 959, USC/ISI, October 1985.
+
+   [19] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
+   1700, USC/ISI, October 1994.
+
+   [20] Sollins, K., and L. Masinter, "Functional Requirements for
+   Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation,
+   December 1994.
+
+   [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for
+   Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
+
+   [22] ISO-8859. International Standard -- Information Processing --
+     8-bit Single-Byte Coded Graphic Character Sets --
+     Part 1: Latin alphabet No. 1, ISO 8859-1:1987.
+     Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
+     Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.
+     Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.
+
+
+
+Fielding, et. al.           Standards Track                   [Page 147]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+     Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
+     Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.
+     Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.
+     Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
+     Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.
+
+   [23] Meyers, J., and M. Rose "The Content-MD5 Header Field", RFC
+   1864, Carnegie Mellon, Dover Beach Consulting, October, 1995.
+
+   [24] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC
+   1900, IAB, February 1996.
+
+   [25] Deutsch, P., "GZIP file format specification version 4.3." RFC
+   1952, Aladdin Enterprises, May 1996.
+
+   [26] Venkata N. Padmanabhan and Jeffrey C. Mogul. Improving HTTP
+   Latency. Computer Networks and ISDN Systems, v. 28, pp. 25-35, Dec.
+   1995.  Slightly revised version of paper in Proc. 2nd International
+   WWW Conf. '94: Mosaic and the Web, Oct. 1994, which is available at
+   http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/
+   HTTPLatency.html.
+
+   [27] Joe Touch, John Heidemann, and Katia Obraczka, "Analysis of HTTP
+   Performance", <URL: http://www.isi.edu/lsam/ib/http-perf/>,
+   USC/Information Sciences Institute, June 1996
+
+   [28] Mills, D., "Network Time Protocol, Version 3, Specification,
+   Implementation and Analysis", RFC 1305, University of Delaware, March
+   1992.
+
+   [29] Deutsch, P., "DEFLATE Compressed Data Format Specification
+   version 1.3." RFC 1951, Aladdin Enterprises, May 1996.
+
+   [30] Spero, S., "Analysis of HTTP Performance Problems"
+   <URL:http://sunsite.unc.edu/mdma-release/http-prob.html>.
+
+   [31] Deutsch, P., and J-L. Gailly, "ZLIB Compressed Data Format
+   Specification version 3.3", RFC 1950, Aladdin Enterprises, Info-ZIP,
+   May 1996.
+
+   [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
+   Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP :
+   Digest Access Authentication", RFC 2069, January 1997.
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 148]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+18 Authors' Addresses
+
+   Roy T. Fielding
+   Department of Information and Computer Science
+   University of California
+   Irvine, CA 92717-3425, USA
+
+   Fax: [phone]
+   EMail: [e-mail]
+
+
+   Jim Gettys
+   MIT Laboratory for Computer Science
+   545 Technology Square
+   Cambridge, MA 02139, USA
+
+   Fax: [phone]
+   EMail: [e-mail]
+
+
+   Jeffrey C. Mogul
+   Western Research Laboratory
+   Digital Equipment Corporation
+   250 University Avenue
+   Palo Alto, California, 94305, USA
+
+   EMail: [e-mail]
+
+
+   Henrik Frystyk Nielsen
+   W3 Consortium
+   MIT Laboratory for Computer Science
+   545 Technology Square
+   Cambridge, MA 02139, USA
+
+   Fax: [phone]
+   EMail: [e-mail]
+
+
+   Tim Berners-Lee
+   Director, W3 Consortium
+   MIT Laboratory for Computer Science
+   545 Technology Square
+   Cambridge, MA 02139, USA
+
+   Fax: [phone]
+   EMail: [e-mail]
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 149]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+19 Appendices
+
+19.1 Internet Media Type message/http
+
+   In addition to defining the HTTP/1.1 protocol, this document serves
+   as the specification for the Internet media type "message/http". The
+   following is to be registered with IANA.
+
+       Media Type name:         message
+       Media subtype name:      http
+       Required parameters:     none
+       Optional parameters:     version, msgtype
+
+        version: The HTTP-Version number of the enclosed message
+                 (e.g., "1.1"). If not present, the version can be
+                 determined from the first line of the body.
+
+        msgtype: The message type -- "request" or "response". If not
+                 present, the type can be determined from the first
+                 line of the body.
+
+       Encoding considerations: only "7bit", "8bit", or "binary" are
+                                permitted
+
+       Security considerations: none
+
+19.2 Internet Media Type multipart/byteranges
+
+   When an HTTP message includes the content of multiple ranges (for
+   example, a response to a request for multiple non-overlapping
+   ranges), these are transmitted as a multipart MIME message. The
+   multipart media type for this purpose is called
+   "multipart/byteranges".
+
+   The multipart/byteranges media type includes two or more parts, each
+   with its own Content-Type and Content-Range fields. The parts are
+   separated using a MIME boundary parameter.
+
+          Media Type name:         multipart
+          Media subtype name:      byteranges
+          Required parameters:     boundary
+          Optional parameters:     none
+
+          Encoding considerations: only "7bit", "8bit", or "binary" are
+                                   permitted
+
+          Security considerations: none
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 150]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+For example:
+
+   HTTP/1.1 206 Partial content
+   Date: Wed, 15 Nov 1995 06:25:24 GMT
+   Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
+   Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
+
+   --THIS_STRING_SEPARATES
+   Content-type: application/pdf
+   Content-range: bytes 500-999/8000
+
+   ...the first range...
+   --THIS_STRING_SEPARATES
+   Content-type: application/pdf
+   Content-range: bytes 7000-7999/8000
+
+   ...the second range
+   --THIS_STRING_SEPARATES--
+
+19.3 Tolerant Applications
+
+   Although this document specifies the requirements for the generation
+   of HTTP/1.1 messages, not all applications will be correct in their
+   implementation. We therefore recommend that operational applications
+   be tolerant of deviations whenever those deviations can be
+   interpreted unambiguously.
+
+   Clients SHOULD be tolerant in parsing the Status-Line and servers
+   tolerant when parsing the Request-Line. In particular, they SHOULD
+   accept any amount of SP or HT characters between fields, even though
+   only a single SP is required.
+
+   The line terminator for message-header fields is the sequence CRLF.
+   However, we recommend that applications, when parsing such headers,
+   recognize a single LF as a line terminator and ignore the leading CR.
+
+   The character set of an entity-body should be labeled as the lowest
+   common denominator of the character codes used within that body, with
+   the exception that no label is preferred over the labels US-ASCII or
+   ISO-8859-1.
+
+   Additional rules for requirements on parsing and encoding of dates
+   and other potential problems with date encodings include:
+
+  o  HTTP/1.1 clients and caches should assume that an RFC-850 date
+     which appears to be more than 50 years in the future is in fact
+     in the past (this helps solve the "year 2000" problem).
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 151]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+  o  An HTTP/1.1 implementation may internally represent a parsed
+     Expires date as earlier than the proper value, but MUST NOT
+     internally represent a parsed Expires date as later than the
+     proper value.
+
+  o  All expiration-related calculations must be done in GMT. The
+     local time zone MUST NOT influence the calculation or comparison
+     of an age or expiration time.
+
+  o  If an HTTP header incorrectly carries a date value with a time
+     zone other than GMT, it must be converted into GMT using the most
+     conservative possible conversion.
+
+19.4 Differences Between HTTP Entities and MIME Entities
+
+   HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
+   822) and the Multipurpose Internet Mail Extensions (MIME ) to allow
+   entities to be transmitted in an open variety of representations and
+   with extensible mechanisms. However, MIME [7] discusses mail, and
+   HTTP has a few features that are different from those described in
+   MIME.  These differences were carefully chosen to optimize
+   performance over binary connections, to allow greater freedom in the
+   use of new media types, to make date comparisons easier, and to
+   acknowledge the practice of some early HTTP servers and clients.
+
+   This appendix describes specific areas where HTTP differs from MIME.
+   Proxies and gateways to strict MIME environments SHOULD be aware of
+   these differences and provide the appropriate conversions where
+   necessary. Proxies and gateways from MIME environments to HTTP also
+   need to be aware of the differences because some conversions may be
+   required.
+
+19.4.1 Conversion to Canonical Form
+
+   MIME requires that an Internet mail entity be converted to canonical
+   form prior to being transferred.  Section 3.7.1 of this document
+   describes the forms allowed for subtypes of the "text" media type
+   when transmitted over HTTP. MIME requires that content with a type of
+   "text" represent line breaks as CRLF and forbids the use of CR or LF
+   outside of line break sequences.  HTTP allows CRLF, bare CR, and bare
+   LF to indicate a line break within text content when a message is
+   transmitted over HTTP.
+
+   Where it is possible, a proxy or gateway from HTTP to a strict MIME
+   environment SHOULD translate all line breaks within the text media
+   types described in section 3.7.1 of this document to the MIME
+   canonical form of CRLF. Note, however, that this may be complicated
+   by the presence of a Content-Encoding and by the fact that HTTP
+
+
+
+Fielding, et. al.           Standards Track                   [Page 152]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   allows the use of some character sets which do not use octets 13 and
+   10 to represent CR and LF, as is the case for some multi-byte
+   character sets.
+
+19.4.2 Conversion of Date Formats
+
+   HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to
+   simplify the process of date comparison. Proxies and gateways from
+   other protocols SHOULD ensure that any Date header field present in a
+   message conforms to one of the HTTP/1.1 formats and rewrite the date
+   if necessary.
+
+19.4.3 Introduction of Content-Encoding
+
+   MIME does not include any concept equivalent to HTTP/1.1's Content-
+   Encoding header field. Since this acts as a modifier on the media
+   type, proxies and gateways from HTTP to MIME-compliant protocols MUST
+   either change the value of the Content-Type header field or decode
+   the entity-body before forwarding the message. (Some experimental
+   applications of Content-Type for Internet mail have used a media-type
+   parameter of ";conversions=<content-coding>" to perform an equivalent
+   function as Content-Encoding. However, this parameter is not part of
+   MIME.)
+
+19.4.4 No Content-Transfer-Encoding
+
+   HTTP does not use the Content-Transfer-Encoding (CTE) field of MIME.
+   Proxies and gateways from MIME-compliant protocols to HTTP MUST
+   remove any non-identity CTE ("quoted-printable" or "base64") encoding
+   prior to delivering the response message to an HTTP client.
+
+   Proxies and gateways from HTTP to MIME-compliant protocols are
+   responsible for ensuring that the message is in the correct format
+   and encoding for safe transport on that protocol, where "safe
+   transport" is defined by the limitations of the protocol being used.
+   Such a proxy or gateway SHOULD label the data with an appropriate
+   Content-Transfer-Encoding if doing so will improve the likelihood of
+   safe transport over the destination protocol.
+
+19.4.5 HTTP Header Fields in Multipart Body-Parts
+
+   In MIME, most header fields in multipart body-parts are generally
+   ignored unless the field name begins with "Content-". In HTTP/1.1,
+   multipart body-parts may contain any HTTP header fields which are
+   significant to the meaning of that part.
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 153]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+19.4.6 Introduction of Transfer-Encoding
+
+   HTTP/1.1 introduces the Transfer-Encoding header field (section
+   14.40).  Proxies/gateways MUST remove any transfer coding prior to
+   forwarding a message via a MIME-compliant protocol.
+
+   A process for decoding the "chunked" transfer coding (section 3.6)
+   can be represented in pseudo-code as:
+
+          length := 0
+          read chunk-size, chunk-ext (if any) and CRLF
+          while (chunk-size > 0) {
+             read chunk-data and CRLF
+             append chunk-data to entity-body
+             length := length + chunk-size
+             read chunk-size and CRLF
+          }
+          read entity-header
+          while (entity-header not empty) {
+             append entity-header to existing header fields
+             read entity-header
+          }
+          Content-Length := length
+          Remove "chunked" from Transfer-Encoding
+
+19.4.7 MIME-Version
+
+   HTTP is not a MIME-compliant protocol (see appendix 19.4). However,
+   HTTP/1.1 messages may include a single MIME-Version general-header
+   field to indicate what version of the MIME protocol was used to
+   construct the message. Use of the MIME-Version header field indicates
+   that the message is in full compliance with the MIME protocol.
+   Proxies/gateways are responsible for ensuring full compliance (where
+   possible) when exporting HTTP messages to strict MIME environments.
+
+          MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
+
+   MIME version "1.0" is the default for use in HTTP/1.1. However,
+   HTTP/1.1 message parsing and semantics are defined by this document
+   and not the MIME specification.
+
+19.5 Changes from HTTP/1.0
+
+   This section summarizes major differences between versions HTTP/1.0
+   and HTTP/1.1.
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 154]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+19.5.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
+       Addresses
+
+   The requirements that clients and servers support the Host request-
+   header, report an error if the Host request-header (section 14.23) is
+   missing from an HTTP/1.1 request, and accept absolute URIs (section
+   5.1.2) are among the most important changes defined by this
+   specification.
+
+   Older HTTP/1.0 clients assumed a one-to-one relationship of IP
+   addresses and servers; there was no other established mechanism for
+   distinguishing the intended server of a request than the IP address
+   to which that request was directed. The changes outlined above will
+   allow the Internet, once older HTTP clients are no longer common, to
+   support multiple Web sites from a single IP address, greatly
+   simplifying large operational Web servers, where allocation of many
+   IP addresses to a single host has created serious problems. The
+   Internet will also be able to recover the IP addresses that have been
+   allocated for the sole purpose of allowing special-purpose domain
+   names to be used in root-level HTTP URLs. Given the rate of growth of
+   the Web, and the number of servers already deployed, it is extremely
+   important that all implementations of HTTP (including updates to
+   existing HTTP/1.0 applications) correctly implement these
+   requirements:
+
+     o  Both clients and servers MUST support the Host request-header.
+
+     o  Host request-headers are required in HTTP/1.1 requests.
+
+     o  Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
+        request does not include a Host request-header.
+
+     o  Servers MUST accept absolute URIs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 155]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+19.6 Additional Features
+
+   This appendix documents protocol elements used by some existing HTTP
+   implementations, but not consistently and correctly across most
+   HTTP/1.1 applications. Implementers should be aware of these
+   features, but cannot rely upon their presence in, or interoperability
+   with, other HTTP/1.1 applications. Some of these describe proposed
+   experimental features, and some describe features that experimental
+   deployment found lacking that are now addressed in the base HTTP/1.1
+   specification.
+
+19.6.1 Additional Request Methods
+
+19.6.1.1 PATCH
+
+   The PATCH method is similar to PUT except that the entity contains a
+   list of differences between the original version of the resource
+   identified by the Request-URI and the desired content of the resource
+   after the PATCH action has been applied. The list of differences is
+   in a format defined by the media type of the entity (e.g.,
+   "application/diff") and MUST include sufficient information to allow
+   the server to recreate the changes necessary to convert the original
+   version of the resource to the desired version.
+
+   If the request passes through a cache and the Request-URI identifies
+   a currently cached entity, that entity MUST be removed from the
+   cache.  Responses to this method are not cachable.
+
+   The actual method for determining how the patched resource is placed,
+   and what happens to its predecessor, is defined entirely by the
+   origin server. If the original version of the resource being patched
+   included a Content-Version header field, the request entity MUST
+   include a Derived-From header field corresponding to the value of the
+   original Content-Version header field. Applications are encouraged to
+   use these fields for constructing versioning relationships and
+   resolving version conflicts.
+
+   PATCH requests must obey the message transmission requirements set
+   out in section 8.2.
+
+   Caches that implement PATCH should invalidate cached responses as
+   defined in section 13.10 for PUT.
+
+19.6.1.2 LINK
+
+   The LINK method establishes one or more Link relationships between
+   the existing resource identified by the Request-URI and other
+   existing resources. The difference between LINK and other methods
+
+
+
+Fielding, et. al.           Standards Track                   [Page 156]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   allowing links to be established between resources is that the LINK
+   method does not allow any message-body to be sent in the request and
+   does not directly result in the creation of new resources.
+
+   If the request passes through a cache and the Request-URI identifies
+   a currently cached entity, that entity MUST be removed from the
+   cache.  Responses to this method are not cachable.
+
+   Caches that implement LINK should invalidate cached responses as
+   defined in section 13.10 for PUT.
+
+19.6.1.3 UNLINK
+
+   The UNLINK method removes one or more Link relationships from the
+   existing resource identified by the Request-URI. These relationships
+   may have been established using the LINK method or by any other
+   method supporting the Link header. The removal of a link to a
+   resource does not imply that the resource ceases to exist or becomes
+   inaccessible for future references.
+
+   If the request passes through a cache and the Request-URI identifies
+   a currently cached entity, that entity MUST be removed from the
+   cache.  Responses to this method are not cachable.
+
+   Caches that implement UNLINK should invalidate cached responses as
+   defined in section 13.10 for PUT.
+
+19.6.2 Additional Header Field Definitions
+
+19.6.2.1 Alternates
+
+   The Alternates response-header field has been proposed as a means for
+   the origin server to inform the client about other available
+   representations of the requested resource, along with their
+   distinguishing attributes, and thus providing a more reliable means
+   for a user agent to perform subsequent selection of another
+   representation which better fits the desires of its user (described
+   as agent-driven negotiation in section 12).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 157]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   The Alternates header field is orthogonal to the Vary header field in
+   that both may coexist in a message without affecting the
+   interpretation of the response or the available representations. It
+   is expected that Alternates will provide a significant improvement
+   over the server-driven negotiation provided by the Vary field for
+   those resources that vary over common dimensions like type and
+   language.
+
+   The Alternates header field will be defined in a future
+   specification.
+
+19.6.2.2 Content-Version
+
+   The Content-Version entity-header field defines the version tag
+   associated with a rendition of an evolving entity. Together with the
+   Derived-From field described in section 19.6.2.3, it allows a group
+   of people to work simultaneously on the creation of a work as an
+   iterative process. The field should be used to allow evolution of a
+   particular work along a single path rather than derived works or
+   renditions in different representations.
+
+          Content-Version = "Content-Version" ":" quoted-string
+
+   Examples of the Content-Version field include:
+
+          Content-Version: "2.1.2"
+          Content-Version: "Fred 19950116-12:26:48"
+          Content-Version: "2.5a4-omega7"
+
+19.6.2.3 Derived-From
+
+   The Derived-From entity-header field can be used to indicate the
+   version tag of the resource from which the enclosed entity was
+   derived before modifications were made by the sender. This field is
+   used to help manage the process of merging successive changes to a
+   resource, particularly when such changes are being made in parallel
+   and from multiple sources.
+
+          Derived-From   = "Derived-From" ":" quoted-string
+
+   An example use of the field is:
+
+          Derived-From: "2.1.1"
+
+   The Derived-From field is required for PUT and PATCH requests if the
+   entity being sent was previously retrieved from the same URI and a
+   Content-Version header was included with the entity when it was last
+   retrieved.
+
+
+
+Fielding, et. al.           Standards Track                   [Page 158]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+19.6.2.4 Link
+
+   The Link entity-header field provides a means for describing a
+   relationship between two resources, generally between the requested
+   resource and some other resource. An entity MAY include multiple Link
+   values. Links at the metainformation level typically indicate
+   relationships like hierarchical structure and navigation paths. The
+   Link field is semantically equivalent to the <LINK> element in
+   HTML.[5]
+
+          Link           = "Link" ":" #("<" URI ">" *( ";" link-param )
+
+          link-param     = ( ( "rel" "=" relationship )
+                             | ( "rev" "=" relationship )
+                             | ( "title" "=" quoted-string )
+                             | ( "anchor" "=" <"> URI <"> )
+                             | ( link-extension ) )
+
+          link-extension = token [ "=" ( token | quoted-string ) ]
+
+          relationship   = sgml-name
+                         | ( <"> sgml-name *( SP sgml-name) <"> )
+
+          sgml-name      = ALPHA *( ALPHA | DIGIT | "." | "-" )
+
+   Relationship values are case-insensitive and MAY be extended within
+   the constraints of the sgml-name syntax. The title parameter MAY be
+   used to label the destination of a link such that it can be used as
+   identification within a human-readable menu. The anchor parameter MAY
+   be used to indicate a source anchor other than the entire current
+   resource, such as a fragment of this resource or a third resource.
+
+   Examples of usage include:
+
+       Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous"
+
+       Link: <mailto:[e-mail]>; rev="Made"; title="Tim Berners-Lee"
+
+   The first example indicates that chapter2 is previous to this
+   resource in a logical navigation path. The second indicates that the
+   person responsible for making the resource available is identified by
+   the given e-mail address.
+
+19.6.2.5 URI
+
+   The URI header field has, in past versions of this specification,
+   been used as a combination of the existing Location, Content-
+   Location, and Vary header fields as well as the future Alternates
+
+
+
+Fielding, et. al.           Standards Track                   [Page 159]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+   field (above). Its primary purpose has been to include a list of
+   additional URIs for the resource, including names and mirror
+   locations. However, it has become clear that the combination of many
+   different functions within this single field has been a barrier to
+   consistently and correctly implementing any of those functions.
+   Furthermore, we believe that the identification of names and mirror
+   locations would be better performed via the Link header field. The
+   URI header field is therefore deprecated in favor of those other
+   fields.
+
+          URI-header    = "URI" ":" 1#( "<" URI ">" )
+
+19.7 Compatibility with Previous Versions
+
+   It is beyond the scope of a protocol specification to mandate
+   compliance with previous versions. HTTP/1.1 was deliberately
+   designed, however, to make supporting previous versions easy. It is
+   worth noting that at the time of composing this specification, we
+   would expect commercial HTTP/1.1 servers to:
+
+  o  recognize the format of the Request-Line for HTTP/0.9, 1.0, and 1.1
+     requests;
+
+  o  understand any valid request in the format of HTTP/0.9, 1.0, or
+     1.1;
+
+  o  respond appropriately with a message in the same major version used
+     by the client.
+
+   And we would expect HTTP/1.1 clients to:
+
+  o  recognize the format of the Status-Line for HTTP/1.0 and 1.1
+     responses;
+
+  o  understand any valid response in the format of HTTP/0.9, 1.0, or
+     1.1.
+
+   For most implementations of HTTP/1.0, each connection is established
+   by the client prior to the request and closed by the server after
+   sending the response. A few implementations implement the Keep-Alive
+   version of persistent connections described in section 19.7.1.1.
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 160]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+19.7.1 Compatibility with HTTP/1.0 Persistent Connections
+
+   Some clients and servers may wish to be compatible with some previous
+   implementations of persistent connections in HTTP/1.0 clients and
+   servers. Persistent connections in HTTP/1.0 must be explicitly
+   negotiated as they are not the default behavior. HTTP/1.0
+   experimental implementations of persistent connections are faulty,
+   and the new facilities in HTTP/1.1 are designed to rectify these
+   problems. The problem was that some existing 1.0 clients may be
+   sending Keep-Alive to a proxy server that doesn't understand
+   Connection, which would then erroneously forward it to the next
+   inbound server, which would establish the Keep-Alive connection and
+   result in a hung HTTP/1.0 proxy waiting for the close on the
+   response. The result is that HTTP/1.0 clients must be prevented from
+   using Keep-Alive when talking to proxies.
+
+   However, talking to proxies is the most important use of persistent
+   connections, so that prohibition is clearly unacceptable. Therefore,
+   we need some other mechanism for indicating a persistent connection
+   is desired, which is safe to use even when talking to an old proxy
+   that ignores Connection. Persistent connections are the default for
+   HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
+   declaring non-persistence.
+
+   The following describes the original HTTP/1.0 form of persistent
+   connections.
+
+   When it connects to an origin server, an HTTP client MAY send the
+   Keep-Alive connection-token in addition to the Persist connection-
+   token:
+
+          Connection: Keep-Alive
+
+   An HTTP/1.0 server would then respond with the Keep-Alive connection
+   token and the client may proceed with an HTTP/1.0 (or Keep-Alive)
+   persistent connection.
+
+   An HTTP/1.1 server may also establish persistent connections with
+   HTTP/1.0 clients upon receipt of a Keep-Alive connection token.
+   However, a persistent connection with an HTTP/1.0 client cannot make
+   use of the chunked transfer-coding, and therefore MUST use a
+   Content-Length for marking the ending boundary of each message.
+
+   A client MUST NOT send the Keep-Alive connection token to a proxy
+   server as HTTP/1.0 proxy servers do not obey the rules of HTTP/1.1
+   for parsing the Connection header field.
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 161]
+
+RFC 2068                        HTTP/1.1                    January 1997
+
+
+19.7.1.1 The Keep-Alive Header
+
+   When the Keep-Alive connection-token has been transmitted with a
+   request or a response, a Keep-Alive header field MAY also be
+   included. The Keep-Alive header field takes the following form:
+
+          Keep-Alive-header = "Keep-Alive" ":" 0# keepalive-param
+
+          keepalive-param = param-name "=" value
+
+   The Keep-Alive header itself is optional, and is used only if a
+   parameter is being sent. HTTP/1.1 does not define any parameters.
+
+   If the Keep-Alive header is sent, the corresponding connection token
+   MUST be transmitted. The Keep-Alive header MUST be ignored if
+   received without the connection token.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al.           Standards Track                   [Page 162]
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/rfcs/rfc2246.txt	Tue Jul 13 01:35:15 2004 +0000
@@ -0,0 +1,4483 @@
+
+
+
+
+
+
+Network Working Group                                         T. Dierks
+Request for Comments: 2246                                     Certicom
+Category: Standards Track                                      C. Allen
+                                                               Certicom
+                                                           January 1999
+
+
+                            The TLS Protocol
+                              Version 1.0
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   This document specifies Version 1.0 of the Transport Layer Security
+   (TLS) protocol. The TLS protocol provides communications privacy over
+   the Internet. The protocol allows client/server applications to
+   communicate in a way that is designed to prevent eavesdropping,
+   tampering, or message forgery.
+
+Table of Contents
+
+   1.       Introduction                                              3
+   2.       Goals                                                     4
+   3.       Goals of this document                                    5
+   4.       Presentation language                                     5
+   4.1.     Basic block size                                          6
+   4.2.     Miscellaneous                                             6
+   4.3.     Vectors                                                   6
+   4.4.     Numbers                                                   7
+   4.5.     Enumerateds                                               7
+   4.6.     Constructed types                                         8
+   4.6.1.   Variants                                                  9
+   4.7.     Cryptographic attributes                                 10
+   4.8.     Constants                                                11
+   5.       HMAC and the pseudorandom function                       11
+   6.       The TLS Record Protocol                                  13
+   6.1.     Connection states                                        14
+
+
+
+Dierks & Allen              Standards Track                     [Page 1]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   6.2.     Record layer                                             16
+   6.2.1.   Fragmentation                                            16
+   6.2.2.   Record compression and decompression                     17
+   6.2.3.   Record payload protection                                18
+   6.2.3.1. Null or standard stream cipher                           19
+   6.2.3.2. CBC block cipher                                         19
+   6.3.     Key calculation                                          21
+   6.3.1.   Export key generation example                            22
+   7.       The TLS Handshake Protocol                               23
+   7.1.     Change cipher spec protocol                              24
+   7.2.     Alert protocol                                           24
+   7.2.1.   Closure alerts                                           25
+   7.2.2.   Error alerts                                             26
+   7.3.     Handshake Protocol overview                              29
+   7.4.     Handshake protocol                                       32
+   7.4.1.   Hello messages                                           33
+   7.4.1.1. Hello request                                            33
+   7.4.1.2. Client hello                                             34
+   7.4.1.3. Server hello                                             36
+   7.4.2.   Server certificate                                       37
+   7.4.3.   Server key exchange message                              39
+   7.4.4.   Certificate request                                      41
+   7.4.5.   Server hello done                                        42
+   7.4.6.   Client certificate                                       43
+   7.4.7.   Client key exchange message                              43
+   7.4.7.1. RSA encrypted premaster secret message                   44
+   7.4.7.2. Client Diffie-Hellman public value                       45
+   7.4.8.   Certificate verify                                       45
+   7.4.9.   Finished                                                 46
+   8.       Cryptographic computations                               47
+   8.1.     Computing the master secret                              47
+   8.1.1.   RSA                                                      48
+   8.1.2.   Diffie-Hellman                                           48
+   9.       Mandatory Cipher Suites                                  48
+   10.      Application data protocol                                48
+   A.       Protocol constant values                                 49
+   A.1.     Record layer                                             49
+   A.2.     Change cipher specs message                              50
+   A.3.     Alert messages                                           50
+   A.4.     Handshake protocol                                       51
+   A.4.1.   Hello messages                                           51
+   A.4.2.   Server authentication and key exchange messages          52
+   A.4.3.   Client authentication and key exchange messages          53
+   A.4.4.   Handshake finalization message                           54
+   A.5.     The CipherSuite                                          54
+   A.6.     The Security Parameters                                  56
+   B.       Glossary                                                 57
+   C.       CipherSuite definitions                                  61
+
+
+
+Dierks & Allen              Standards Track                     [Page 2]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   D.       Implementation Notes                                     64
+   D.1.     Temporary RSA keys                                       64
+   D.2.     Random Number Generation and Seeding                     64
+   D.3.     Certificates and authentication                          65
+   D.4.     CipherSuites                                             65
+   E.       Backward Compatibility With SSL                          66
+   E.1.     Version 2 client hello                                   67
+   E.2.     Avoiding man-in-the-middle version rollback              68
+   F.       Security analysis                                        69
+   F.1.     Handshake protocol                                       69
+   F.1.1.   Authentication and key exchange                          69
+   F.1.1.1. Anonymous key exchange                                   69
+   F.1.1.2. RSA key exchange and authentication                      70
+   F.1.1.3. Diffie-Hellman key exchange with authentication          71
+   F.1.2.   Version rollback attacks                                 71
+   F.1.3.   Detecting attacks against the handshake protocol         72
+   F.1.4.   Resuming sessions                                        72
+   F.1.5.   MD5 and SHA                                              72
+   F.2.     Protecting application data                              72
+   F.3.     Final notes                                              73
+   G.       Patent Statement                                         74
+            Security Considerations                                  75
+            References                                               75
+            Credits                                                  77
+            Comments                                                 78
+            Full Copyright Statement                                 80
+
+1. Introduction
+
+   The primary goal of the TLS Protocol is to provide privacy and data
+   integrity between two communicating applications. The protocol is
+   composed of two layers: the TLS Record Protocol and the TLS Handshake
+   Protocol. At the lowest level, layered on top of some reliable
+   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
+   TLS Record Protocol provides connection security that has two basic
+   properties:
+
+     - The connection is private. Symmetric cryptography is used for
+       data encryption (e.g., DES [DES], RC4 [RC4], etc.) The keys for
+       this symmetric encryption are generated uniquely for each
+       connection and are based on a secret negotiated by another
+       protocol (such as the TLS Handshake Protocol). The Record
+       Protocol can also be used without encryption.
+
+     - The connection is reliable. Message transport includes a message
+       integrity check using a keyed MAC. Secure hash functions (e.g.,
+       SHA, MD5, etc.) are used for MAC computations. The Record
+       Protocol can operate without a MAC, but is generally only used in
+
+
+
+Dierks & Allen              Standards Track                     [Page 3]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       this mode while another protocol is using the Record Protocol as
+       a transport for negotiating security parameters.
+
+   The TLS Record Protocol is used for encapsulation of various higher
+   level protocols. One such encapsulated protocol, the TLS Handshake
+   Protocol, allows the server and client to authenticate each other and
+   to negotiate an encryption algorithm and cryptographic keys before
+   the application protocol transmits or receives its first byte of
+   data. The TLS Handshake Protocol provides connection security that
+   has three basic properties:
+
+     - The peer's identity can be authenticated using asymmetric, or
+       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
+       authentication can be made optional, but is generally required
+       for at least one of the peers.
+
+     - The negotiation of a shared secret is secure: the negotiated
+       secret is unavailable to eavesdroppers, and for any authenticated
+       connection the secret cannot be obtained, even by an attacker who
+       can place himself in the middle of the connection.
+
+     - The negotiation is reliable: no attacker can modify the
+       negotiation communication without being detected by the parties
+       to the communication.
+
+   One advantage of TLS is that it is application protocol independent.
+   Higher level protocols can layer on top of the TLS Protocol
+   transparently. The TLS standard, however, does not specify how
+   protocols add security with TLS; the decisions on how to initiate TLS
+   handshaking and how to interpret the authentication certificates
+   exchanged are left up to the judgment of the designers and
+   implementors of protocols which run on top of TLS.
+
+2. Goals
+
+   The goals of TLS Protocol, in order of their priority, are:
+
+    1. Cryptographic security: TLS should be used to establish a secure
+       connection between two parties.
+
+    2. Interoperability: Independent programmers should be able to
+       develop applications utilizing TLS that will then be able to
+       successfully exchange cryptographic parameters without knowledge
+       of one another's code.
+
+    3. Extensibility: TLS seeks to provide a framework into which new
+       public key and bulk encryption methods can be incorporated as
+       necessary. This will also accomplish two sub-goals: to prevent
+
+
+
+Dierks & Allen              Standards Track                     [Page 4]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       the need to create a new protocol (and risking the introduction
+       of possible new weaknesses) and to avoid the need to implement an
+       entire new security library.
+
+    4. Relative efficiency: Cryptographic operations tend to be highly
+       CPU intensive, particularly public key operations. For this
+       reason, the TLS protocol has incorporated an optional session
+       caching scheme to reduce the number of connections that need to
+       be established from scratch. Additionally, care has been taken to
+       reduce network activity.
+
+3. Goals of this document
+
+   This document and the TLS protocol itself are based on the SSL 3.0
+   Protocol Specification as published by Netscape. The differences
+   between this protocol and SSL 3.0 are not dramatic, but they are
+   significant enough that TLS 1.0 and SSL 3.0 do not interoperate
+   (although TLS 1.0 does incorporate a mechanism by which a TLS
+   implementation can back down to SSL 3.0). This document is intended
+   primarily for readers who will be implementing the protocol and those
+   doing cryptographic analysis of it. The specification has been
+   written with this in mind, and it is intended to reflect the needs of
+   those two groups. For that reason, many of the algorithm-dependent
+   data structures and rules are included in the body of the text (as
+   opposed to in an appendix), providing easier access to them.
+
+   This document is not intended to supply any details of service
+   definition nor interface definition, although it does cover select
+   areas of policy as they are required for the maintenance of solid
+   security.
+
+4. Presentation language
+
+   This document deals with the formatting of data in an external
+   representation. The following very basic and somewhat casually
+   defined presentation syntax will be used. The syntax draws from
+   several sources in its structure. Although it resembles the
+   programming language "C" in its syntax and XDR [XDR] in both its
+   syntax and intent, it would be risky to draw too many parallels. The
+   purpose of this presentation language is to document TLS only, not to
+   have general application beyond that particular goal.
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                     [Page 5]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+4.1. Basic block size
+
+   The representation of all data items is explicitly specified. The
+   basic data block size is one byte (i.e. 8 bits). Multiple byte data
+   items are concatenations of bytes, from left to right, from top to
+   bottom. From the bytestream a multi-byte item (a numeric in the
+   example) is formed (using C notation) by:
+
+       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
+               ... | byte[n-1];
+
+   This byte ordering for multi-byte values is the commonplace network
+   byte order or big endian format.
+
+4.2. Miscellaneous
+
+   Comments begin with "/*" and end with "*/".
+
+   Optional components are denoted by enclosing them in "[[ ]]" double
+   brackets.
+
+   Single byte entities containing uninterpreted data are of type
+   opaque.
+
+4.3. Vectors
+
+   A vector (single dimensioned array) is a stream of homogeneous data
+   elements. The size of the vector may be specified at documentation
+   time or left unspecified until runtime. In either case the length
+   declares the number of bytes, not the number of elements, in the
+   vector. The syntax for specifying a new type T' that is a fixed
+   length vector of type T is
+
+       T T'[n];
+
+   Here T' occupies n bytes in the data stream, where n is a multiple of
+   the size of T. The length of the vector is not included in the
+   encoded stream.
+
+   In the following example, Datum is defined to be three consecutive
+   bytes that the protocol does not interpret, while Data is three
+   consecutive Datum, consuming a total of nine bytes.
+
+       opaque Datum[3];      /* three uninterpreted bytes */
+       Datum Data[9];        /* 3 consecutive 3 byte vectors */
+
+
+
+
+
+
+Dierks & Allen              Standards Track                     [Page 6]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Variable length vectors are defined by specifying a subrange of legal
+   lengths, inclusively, using the notation <floor..ceiling>.  When
+   encoded, the actual length precedes the vector's contents in the byte
+   stream. The length will be in the form of a number consuming as many
+   bytes as required to hold the vector's specified maximum (ceiling)
+   length. A variable length vector with an actual length field of zero
+   is referred to as an empty vector.
+
+       T T'<floor..ceiling>;
+
+   In the following example, mandatory is a vector that must contain
+   between 300 and 400 bytes of type opaque. It can never be empty. The
+   actual length field consumes two bytes, a uint16, sufficient to
+   represent the value 400 (see Section 4.4). On the other hand, longer
+   can represent up to 800 bytes of data, or 400 uint16 elements, and it
+   may be empty. Its encoding will include a two byte actual length
+   field prepended to the vector. The length of an encoded vector must
+   be an even multiple of the length of a single element (for example, a
+   17 byte vector of uint16 would be illegal).
+
+       opaque mandatory<300..400>;
+             /* length field is 2 bytes, cannot be empty */
+       uint16 longer<0..800>;
+             /* zero to 400 16-bit unsigned integers */
+
+4.4. Numbers
+
+   The basic numeric data type is an unsigned byte (uint8). All larger
+   numeric data types are formed from fixed length series of bytes
+   concatenated as described in Section 4.1 and are also unsigned. The
+   following numeric types are predefined.
+
+       uint8 uint16[2];
+       uint8 uint24[3];
+       uint8 uint32[4];
+       uint8 uint64[8];
+
+   All values, here and elsewhere in the specification, are stored in
+   "network" or "big-endian" order; the uint32 represented by the hex
+   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
+
+4.5. Enumerateds
+
+   An additional sparse data type is available called enum. A field of
+   type enum can only assume the values declared in the definition.
+   Each definition is a different type. Only enumerateds of the same
+   type may be assigned or compared. Every element of an enumerated must
+
+
+
+
+Dierks & Allen              Standards Track                     [Page 7]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   be assigned a value, as demonstrated in the following example.  Since
+   the elements of the enumerated are not ordered, they can be assigned
+   any unique value, in any order.
+
+       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
+
+   Enumerateds occupy as much space in the byte stream as would its
+   maximal defined ordinal value. The following definition would cause
+   one byte to be used to carry fields of type Color.
+
+       enum { red(3), blue(5), white(7) } Color;
+
+   One may optionally specify a value without its associated tag to
+   force the width definition without defining a superfluous element.
+   In the following example, Taste will consume two bytes in the data
+   stream but can only assume the values 1, 2 or 4.
+
+       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
+
+   The names of the elements of an enumeration are scoped within the
+   defined type. In the first example, a fully qualified reference to
+   the second element of the enumeration would be Color.blue. Such
+   qualification is not required if the target of the assignment is well
+   specified.
+
+       Color color = Color.blue;     /* overspecified, legal */
+       Color color = blue;           /* correct, type implicit */
+
+   For enumerateds that are never converted to external representation,
+   the numerical information may be omitted.
+
+       enum { low, medium, high } Amount;
+
+4.6. Constructed types
+
+   Structure types may be constructed from primitive types for
+   convenience. Each specification declares a new, unique type. The
+   syntax for definition is much like that of C.
+
+       struct {
+         T1 f1;
+         T2 f2;
+         ...
+         Tn fn;
+       } [[T]];
+
+
+
+
+
+
+Dierks & Allen              Standards Track                     [Page 8]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   The fields within a structure may be qualified using the type's name
+   using a syntax much like that available for enumerateds. For example,
+   T.f2 refers to the second field of the previous declaration.
+   Structure definitions may be embedded.
+
+4.6.1. Variants
+
+   Defined structures may have variants based on some knowledge that is
+   available within the environment. The selector must be an enumerated
+   type that defines the possible variants the structure defines. There
+   must be a case arm for every element of the enumeration declared in
+   the select. The body of the variant structure may be given a label
+   for reference. The mechanism by which the variant is selected at
+   runtime is not prescribed by the presentation language.
+
+       struct {
+           T1 f1;
+           T2 f2;
+           ....
+           Tn fn;
+           select (E) {
+               case e1: Te1;
+               case e2: Te2;
+               ....
+               case en: Ten;
+           } [[fv]];
+       } [[Tv]];
+
+   For example:
+
+       enum { apple, orange } VariantTag;
+       struct {
+           uint16 number;
+           opaque string<0..10>; /* variable length */
+       } V1;
+       struct {
+           uint32 number;
+           opaque string[10];    /* fixed length */
+       } V2;
+       struct {
+           select (VariantTag) { /* value of selector is implicit */
+               case apple: V1;   /* VariantBody, tag = apple */
+               case orange: V2;  /* VariantBody, tag = orange */
+           } variant_body;       /* optional label on variant */
+       } VariantRecord;
+
+   Variant structures may be qualified (narrowed) by specifying a value
+   for the selector prior to the type. For example, a
+
+
+
+Dierks & Allen              Standards Track                     [Page 9]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       orange VariantRecord
+
+   is a narrowed type of a VariantRecord containing a variant_body of
+   type V2.
+
+4.7. Cryptographic attributes
+
+   The four cryptographic operations digital signing, stream cipher
+   encryption, block cipher encryption, and public key encryption are
+   designated digitally-signed, stream-ciphered, block-ciphered, and
+   public-key-encrypted, respectively. A field's cryptographic
+   processing is specified by prepending an appropriate key word
+   designation before the field's type specification. Cryptographic keys
+   are implied by the current session state (see Section 6.1).
+
+   In digital signing, one-way hash functions are used as input for a
+   signing algorithm. A digitally-signed element is encoded as an opaque
+   vector <0..2^16-1>, where the length is specified by the signing
+   algorithm and key.
+
+   In RSA signing, a 36-byte structure of two hashes (one SHA and one
+   MD5) is signed (encrypted with the private key). It is encoded with
+   PKCS #1 block type 0 or type 1 as described in [PKCS1].
+
+   In DSS, the 20 bytes of the SHA hash are run directly through the
+   Digital Signing Algorithm with no additional hashing. This produces
+   two values, r and s. The DSS signature is an opaque vector, as above,
+   the contents of which are the DER encoding of:
+
+       Dss-Sig-Value  ::=  SEQUENCE  {
+            r       INTEGER,
+            s       INTEGER
+       }
+
+   In stream cipher encryption, the plaintext is exclusive-ORed with an
+   identical amount of output generated from a cryptographically-secure
+   keyed pseudorandom number generator.
+
+   In block cipher encryption, every block of plaintext encrypts to a
+   block of ciphertext. All block cipher encryption is done in CBC
+   (Cipher Block Chaining) mode, and all items which are block-ciphered
+   will be an exact multiple of the cipher block length.
+
+   In public key encryption, a public key algorithm is used to encrypt
+   data in such a way that it can be decrypted only with the matching
+   private key. A public-key-encrypted element is encoded as an opaque
+   vector <0..2^16-1>, where the length is specified by the signing
+   algorithm and key.
+
+
+
+Dierks & Allen              Standards Track                    [Page 10]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   An RSA encrypted value is encoded with PKCS #1 block type 2 as
+   described in [PKCS1].
+
+   In the following example:
+
+       stream-ciphered struct {
+           uint8 field1;
+           uint8 field2;
+           digitally-signed opaque hash[20];
+       } UserType;
+
+   The contents of hash are used as input for the signing algorithm,
+   then the entire structure is encrypted with a stream cipher. The
+   length of this structure, in bytes would be equal to 2 bytes for
+   field1 and field2, plus two bytes for the length of the signature,
+   plus the length of the output of the signing algorithm. This is known
+   due to the fact that the algorithm and key used for the signing are
+   known prior to encoding or decoding this structure.
+
+4.8. Constants
+
+   Typed constants can be defined for purposes of specification by
+   declaring a symbol of the desired type and assigning values to it.
+   Under-specified types (opaque, variable length vectors, and
+   structures that contain opaque) cannot be assigned values. No fields
+   of a multi-element structure or vector may be elided.
+
+   For example,
+
+       struct {
+           uint8 f1;
+           uint8 f2;
+       } Example1;
+
+       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
+
+5. HMAC and the pseudorandom function
+
+   A number of operations in the TLS record and handshake layer required
+   a keyed MAC; this is a secure digest of some data protected by a
+   secret. Forging the MAC is infeasible without knowledge of the MAC
+   secret. The construction we use for this operation is known as HMAC,
+   described in [HMAC].
+
+   HMAC can be used with a variety of different hash algorithms. TLS
+   uses it in the handshake with two different algorithms: MD5 and SHA-
+   1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 11]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   data). Additional hash algorithms can be defined by cipher suites and
+   used to protect record data, but MD5 and SHA-1 are hard coded into
+   the description of the handshaking for this version of the protocol.
+
+   In addition, a construction is required to do expansion of secrets
+   into blocks of data for the purposes of key generation or validation.
+   This pseudo-random function (PRF) takes as input a secret, a seed,
+   and an identifying label and produces an output of arbitrary length.
+
+   In order to make the PRF as secure as possible, it uses two hash
+   algorithms in a way which should guarantee its security if either
+   algorithm remains secure.
+
+   First, we define a data expansion function, P_hash(secret, data)
+   which uses a single hash function to expand a secret and seed into an
+   arbitrary quantity of output:
+
+       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
+                              HMAC_hash(secret, A(2) + seed) +
+                              HMAC_hash(secret, A(3) + seed) + ...
+
+   Where + indicates concatenation.
+
+   A() is defined as:
+       A(0) = seed
+       A(i) = HMAC_hash(secret, A(i-1))
+
+   P_hash can be iterated as many times as is necessary to produce the
+   required quantity of data. For example, if P_SHA-1 was being used to
+   create 64 bytes of data, it would have to be iterated 4 times
+   (through A(4)), creating 80 bytes of output data; the last 16 bytes
+   of the final iteration would then be discarded, leaving 64 bytes of
+   output data.
+
+   TLS's PRF is created by splitting the secret into two halves and
+   using one half to generate data with P_MD5 and the other half to
+   generate data with P_SHA-1, then exclusive-or'ing the outputs of
+   these two expansion functions together.
+
+   S1 and S2 are the two halves of the secret and each is the same
+   length. S1 is taken from the first half of the secret, S2 from the
+   second half. Their length is created by rounding up the length of the
+   overall secret divided by two; thus, if the original secret is an odd
+   number of bytes long, the last byte of S1 will be the same as the
+   first byte of S2.
+
+       L_S = length in bytes of secret;
+       L_S1 = L_S2 = ceil(L_S / 2);
+
+
+
+Dierks & Allen              Standards Track                    [Page 12]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   The secret is partitioned into two halves (with the possibility of
+   one shared byte) as described above, S1 taking the first L_S1 bytes
+   and S2 the last L_S2 bytes.
+
+   The PRF is then defined as the result of mixing the two pseudorandom
+   streams by exclusive-or'ing them together.
+
+       PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
+                                  P_SHA-1(S2, label + seed);
+
+   The label is an ASCII string. It should be included in the exact form
+   it is given without a length byte or trailing null character.  For
+   example, the label "slithy toves" would be processed by hashing the
+   following bytes:
+
+       73 6C 69 74 68 79 20 74 6F 76 65 73
+
+   Note that because MD5 produces 16 byte outputs and SHA-1 produces 20
+   byte outputs, the boundaries of their internal iterations will not be
+   aligned; to generate a 80 byte output will involve P_MD5 being
+   iterated through A(5), while P_SHA-1 will only iterate through A(4).
+
+6. The TLS Record Protocol
+
+   The TLS Record Protocol is a layered protocol. At each layer,
+   messages may include fields for length, description, and content.
+   The Record Protocol takes messages to be transmitted, fragments the
+   data into manageable blocks, optionally compresses the data, applies
+   a MAC, encrypts, and transmits the result. Received data is
+   decrypted, verified, decompressed, and reassembled, then delivered to
+   higher level clients.
+
+   Four record protocol clients are described in this document: the
+   handshake protocol, the alert protocol, the change cipher spec
+   protocol, and the application data protocol. In order to allow
+   extension of the TLS protocol, additional record types can be
+   supported by the record protocol. Any new record types should
+   allocate type values immediately beyond the ContentType values for
+   the four record types described here (see Appendix A.2). If a TLS
+   implementation receives a record type it does not understand, it
+   should just ignore it. Any protocol designed for use over TLS must be
+   carefully designed to deal with all possible attacks against it.
+   Note that because the type and length of a record are not protected
+   by encryption, care should be take to minimize the value of traffic
+   analysis of these values.
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 13]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+6.1. Connection states
+
+   A TLS connection state is the operating environment of the TLS Record
+   Protocol. It specifies a compression algorithm, encryption algorithm,
+   and MAC algorithm. In addition, the parameters for these algorithms
+   are known: the MAC secret and the bulk encryption keys and IVs for
+   the connection in both the read and the write directions. Logically,
+   there are always four connection states outstanding: the current read
+   and write states, and the pending read and write states. All records
+   are processed under the current read and write states. The security
+   parameters for the pending states can be set by the TLS Handshake
+   Protocol, and the Handshake Protocol can selectively make either of
+   the pending states current, in which case the appropriate current
+   state is disposed of and replaced with the pending state; the pending
+   state is then reinitialized to an empty state. It is illegal to make
+   a state which has not been initialized with security parameters a
+   current state. The initial current state always specifies that no
+   encryption, compression, or MAC will be used.
+
+   The security parameters for a TLS Connection read and write state are
+   set by providing the following values:
+
+   connection end
+       Whether this entity is considered the "client" or the "server" in
+       this connection.
+
+   bulk encryption algorithm
+       An algorithm to be used for bulk encryption. This specification
+       includes the key size of this algorithm, how much of that key is
+       secret, whether it is a block or stream cipher, the block size of
+       the cipher (if appropriate), and whether it is considered an
+       "export" cipher.
+
+   MAC algorithm
+       An algorithm to be used for message authentication. This
+       specification includes the size of the hash which is returned by
+       the MAC algorithm.
+
+   compression algorithm
+       An algorithm to be used for data compression. This specification
+       must include all information the algorithm requires to do
+       compression.
+
+   master secret
+       A 48 byte secret shared between the two peers in the connection.
+
+   client random
+       A 32 byte value provided by the client.
+
+
+
+Dierks & Allen              Standards Track                    [Page 14]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   server random
+       A 32 byte value provided by the server.
+
+   These parameters are defined in the presentation language as:
+
+       enum { server, client } ConnectionEnd;
+
+       enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;
+
+       enum { stream, block } CipherType;
+
+       enum { true, false } IsExportable;
+
+       enum { null, md5, sha } MACAlgorithm;
+
+       enum { null(0), (255) } CompressionMethod;
+
+       /* The algorithms specified in CompressionMethod,
+          BulkCipherAlgorithm, and MACAlgorithm may be added to. */
+
+       struct {
+           ConnectionEnd          entity;
+           BulkCipherAlgorithm    bulk_cipher_algorithm;
+           CipherType             cipher_type;
+           uint8                  key_size;
+           uint8                  key_material_length;
+           IsExportable           is_exportable;
+           MACAlgorithm           mac_algorithm;
+           uint8                  hash_size;
+           CompressionMethod      compression_algorithm;
+           opaque                 master_secret[48];
+           opaque                 client_random[32];
+           opaque                 server_random[32];
+       } SecurityParameters;
+
+   The record layer will use the security parameters to generate the
+   following six items:
+
+       client write MAC secret
+       server write MAC secret
+       client write key
+       server write key
+       client write IV (for block ciphers only)
+       server write IV (for block ciphers only)
+
+   The client write parameters are used by the server when receiving and
+   processing records and vice-versa. The algorithm used for generating
+   these items from the security parameters is described in section 6.3.
+
+
+
+Dierks & Allen              Standards Track                    [Page 15]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Once the security parameters have been set and the keys have been
+   generated, the connection states can be instantiated by making them
+   the current states. These current states must be updated for each
+   record processed. Each connection state includes the following
+   elements:
+
+   compression state
+       The current state of the compression algorithm.
+
+   cipher state
+       The current state of the encryption algorithm. This will consist
+       of the scheduled key for that connection. In addition, for block
+       ciphers running in CBC mode (the only mode specified for TLS),
+       this will initially contain the IV for that connection state and
+       be updated to contain the ciphertext of the last block encrypted
+       or decrypted as records are processed. For stream ciphers, this
+       will contain whatever the necessary state information is to allow
+       the stream to continue to encrypt or decrypt data.
+
+   MAC secret
+       The MAC secret for this connection as generated above.
+
+   sequence number
+       Each connection state contains a sequence number, which is
+       maintained separately for read and write states. The sequence
+       number must be set to zero whenever a connection state is made
+       the active state. Sequence numbers are of type uint64 and may not
+       exceed 2^64-1. A sequence number is incremented after each
+       record: specifically, the first record which is transmitted under
+       a particular connection state should use sequence number 0.
+
+6.2. Record layer
+
+   The TLS Record Layer receives uninterpreted data from higher layers
+   in non-empty blocks of arbitrary size.
+
+6.2.1. Fragmentation
+
+   The record layer fragments information blocks into TLSPlaintext
+   records carrying data in chunks of 2^14 bytes or less. Client message
+   boundaries are not preserved in the record layer (i.e., multiple
+   client messages of the same ContentType may be coalesced into a
+   single TLSPlaintext record, or a single message may be fragmented
+   across several records).
+
+       struct {
+           uint8 major, minor;
+       } ProtocolVersion;
+
+
+
+Dierks & Allen              Standards Track                    [Page 16]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       enum {
+           change_cipher_spec(20), alert(21), handshake(22),
+           application_data(23), (255)
+       } ContentType;
+
+       struct {
+           ContentType type;
+           ProtocolVersion version;
+           uint16 length;
+           opaque fragment[TLSPlaintext.length];
+       } TLSPlaintext;
+
+   type
+       The higher level protocol used to process the enclosed fragment.
+
+   version
+       The version of the protocol being employed. This document
+       describes TLS Version 1.0, which uses the version { 3, 1 }. The
+       version value 3.1 is historical: TLS version 1.0 is a minor
+       modification to the SSL 3.0 protocol, which bears the version
+       value 3.0. (See Appendix A.1).
+
+   length
+       The length (in bytes) of the following TLSPlaintext.fragment.
+       The length should not exceed 2^14.
+
+   fragment
+       The application data. This data is transparent and treated as an
+       independent block to be dealt with by the higher level protocol
+       specified by the type field.
+
+ Note: Data of different TLS Record layer content types may be
+       interleaved. Application data is generally of lower precedence
+       for transmission than other content types.
+
+6.2.2. Record compression and decompression
+
+   All records are compressed using the compression algorithm defined in
+   the current session state. There is always an active compression
+   algorithm; however, initially it is defined as
+   CompressionMethod.null. The compression algorithm translates a
+   TLSPlaintext structure into a TLSCompressed structure. Compression
+   functions are initialized with default state information whenever a
+   connection state is made active.
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 17]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Compression must be lossless and may not increase the content length
+   by more than 1024 bytes. If the decompression function encounters a
+   TLSCompressed.fragment that would decompress to a length in excess of
+   2^14 bytes, it should report a fatal decompression failure error.
+
+       struct {
+           ContentType type;       /* same as TLSPlaintext.type */
+           ProtocolVersion version;/* same as TLSPlaintext.version */
+           uint16 length;
+           opaque fragment[TLSCompressed.length];
+       } TLSCompressed;
+
+   length
+       The length (in bytes) of the following TLSCompressed.fragment.
+       The length should not exceed 2^14 + 1024.
+
+   fragment
+       The compressed form of TLSPlaintext.fragment.
+
+ Note: A CompressionMethod.null operation is an identity operation; no
+       fields are altered.
+
+   Implementation note:
+       Decompression functions are responsible for ensuring that
+       messages cannot cause internal buffer overflows.
+
+6.2.3. Record payload protection
+
+   The encryption and MAC functions translate a TLSCompressed structure
+   into a TLSCiphertext. The decryption functions reverse the process.
+   The MAC of the record also includes a sequence number so that
+   missing, extra or repeated messages are detectable.
+
+       struct {
+           ContentType type;
+           ProtocolVersion version;
+           uint16 length;
+           select (CipherSpec.cipher_type) {
+               case stream: GenericStreamCipher;
+               case block: GenericBlockCipher;
+           } fragment;
+       } TLSCiphertext;
+
+   type
+       The type field is identical to TLSCompressed.type.
+
+   version
+       The version field is identical to TLSCompressed.version.
+
+
+
+Dierks & Allen              Standards Track                    [Page 18]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   length
+       The length (in bytes) of the following TLSCiphertext.fragment.
+       The length may not exceed 2^14 + 2048.
+
+   fragment
+       The encrypted form of TLSCompressed.fragment, with the MAC.
+
+6.2.3.1. Null or standard stream cipher
+
+   Stream ciphers (including BulkCipherAlgorithm.null - see Appendix
+   A.6) convert TLSCompressed.fragment structures to and from stream
+   TLSCiphertext.fragment structures.
+
+       stream-ciphered struct {
+           opaque content[TLSCompressed.length];
+           opaque MAC[CipherSpec.hash_size];
+       } GenericStreamCipher;
+
+   The MAC is generated as:
+
+       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
+                     TLSCompressed.version + TLSCompressed.length +
+                     TLSCompressed.fragment));
+
+   where "+" denotes concatenation.
+
+   seq_num
+       The sequence number for this record.
+
+   hash
+       The hashing algorithm specified by
+       SecurityParameters.mac_algorithm.
+
+   Note that the MAC is computed before encryption. The stream cipher
+   encrypts the entire block, including the MAC. For stream ciphers that
+   do not use a synchronization vector (such as RC4), the stream cipher
+   state from the end of one record is simply used on the subsequent
+   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
+   consists of the identity operation (i.e., the data is not encrypted
+   and the MAC size is zero implying that no MAC is used).
+   TLSCiphertext.length is TLSCompressed.length plus
+   CipherSpec.hash_size.
+
+6.2.3.2. CBC block cipher
+
+   For block ciphers (such as RC2 or DES), the encryption and MAC
+   functions convert TLSCompressed.fragment structures to and from block
+   TLSCiphertext.fragment structures.
+
+
+
+Dierks & Allen              Standards Track                    [Page 19]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       block-ciphered struct {
+           opaque content[TLSCompressed.length];
+           opaque MAC[CipherSpec.hash_size];
+           uint8 padding[GenericBlockCipher.padding_length];
+           uint8 padding_length;
+       } GenericBlockCipher;
+
+   The MAC is generated as described in Section 6.2.3.1.
+
+   padding
+       Padding that is added to force the length of the plaintext to be
+       an integral multiple of the block cipher's block length. The
+       padding may be any length up to 255 bytes long, as long as it
+       results in the TLSCiphertext.length being an integral multiple of
+       the block length. Lengths longer than necessary might be
+       desirable to frustrate attacks on a protocol based on analysis of
+       the lengths of exchanged messages. Each uint8 in the padding data
+       vector must be filled with the padding length value.
+
+   padding_length
+       The padding length should be such that the total size of the
+       GenericBlockCipher structure is a multiple of the cipher's block
+       length. Legal values range from zero to 255, inclusive. This
+       length specifies the length of the padding field exclusive of the
+       padding_length field itself.
+
+   The encrypted data length (TLSCiphertext.length) is one more than the
+   sum of TLSCompressed.length, CipherSpec.hash_size, and
+   padding_length.
+
+ Example: If the block length is 8 bytes, the content length
+          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
+          bytes, the length before padding is 82 bytes. Thus, the
+          padding length modulo 8 must be equal to 6 in order to make
+          the total length an even multiple of 8 bytes (the block
+          length). The padding length can be 6, 14, 22, and so on,
+          through 254. If the padding length were the minimum necessary,
+          6, the padding would be 6 bytes, each containing the value 6.
+          Thus, the last 8 octets of the GenericBlockCipher before block
+          encryption would be xx 06 06 06 06 06 06 06, where xx is the
+          last octet of the MAC.
+
+ Note: With block ciphers in CBC mode (Cipher Block Chaining) the
+       initialization vector (IV) for the first record is generated with
+       the other keys and secrets when the security parameters are set.
+       The IV for subsequent records is the last ciphertext block from
+       the previous record.
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 20]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+6.3. Key calculation
+
+   The Record Protocol requires an algorithm to generate keys, IVs, and
+   MAC secrets from the security parameters provided by the handshake
+   protocol.
+
+   The master secret is hashed into a sequence of secure bytes, which
+   are assigned to the MAC secrets, keys, and non-export IVs required by
+   the current connection state (see Appendix A.6). CipherSpecs require
+   a client write MAC secret, a server write MAC secret, a client write
+   key, a server write key, a client write IV, and a server write IV,
+   which are generated from the master secret in that order. Unused
+   values are empty.
+
+   When generating keys and MAC secrets, the master secret is used as an
+   entropy source, and the random values provide unencrypted salt
+   material and IVs for exportable ciphers.
+
+   To generate the key material, compute
+
+       key_block = PRF(SecurityParameters.master_secret,
+                          "key expansion",
+                          SecurityParameters.server_random +
+                          SecurityParameters.client_random);
+
+   until enough output has been generated. Then the key_block is
+   partitioned as follows:
+
+       client_write_MAC_secret[SecurityParameters.hash_size]
+       server_write_MAC_secret[SecurityParameters.hash_size]
+       client_write_key[SecurityParameters.key_material_length]
+       server_write_key[SecurityParameters.key_material_length]
+       client_write_IV[SecurityParameters.IV_size]
+       server_write_IV[SecurityParameters.IV_size]
+
+   The client_write_IV and server_write_IV are only generated for non-
+   export block ciphers. For exportable block ciphers, the
+   initialization vectors are generated later, as described below. Any
+   extra key_block material is discarded.
+
+   Implementation note:
+       The cipher spec which is defined in this document which requires
+       the most material is 3DES_EDE_CBC_SHA: it requires 2 x 24 byte
+       keys, 2 x 20 byte MAC secrets, and 2 x 8 byte IVs, for a total of
+       104 bytes of key material.
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 21]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Exportable encryption algorithms (for which CipherSpec.is_exportable
+   is true) require additional processing as follows to derive their
+   final write keys:
+
+       final_client_write_key =
+       PRF(SecurityParameters.client_write_key,
+                                  "client write key",
+                                  SecurityParameters.client_random +
+                                  SecurityParameters.server_random);
+       final_server_write_key =
+       PRF(SecurityParameters.server_write_key,
+                                  "server write key",
+                                  SecurityParameters.client_random +
+                                  SecurityParameters.server_random);
+
+   Exportable encryption algorithms derive their IVs solely from the
+   random values from the hello messages:
+
+       iv_block = PRF("", "IV block", SecurityParameters.client_random +
+                      SecurityParameters.server_random);
+
+   The iv_block is partitioned into two initialization vectors as the
+   key_block was above:
+
+       client_write_IV[SecurityParameters.IV_size]
+       server_write_IV[SecurityParameters.IV_size]
+
+   Note that the PRF is used without a secret in this case: this just
+   means that the secret has a length of zero bytes and contributes
+   nothing to the hashing in the PRF.
+
+6.3.1. Export key generation example
+
+   TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for
+   each of the two encryption keys and 16 bytes for each of the MAC
+   keys, for a total of 42 bytes of key material. The PRF output is
+   stored in the key_block. The key_block is partitioned, and the write
+   keys are salted because this is an exportable encryption algorithm.
+
+       key_block               = PRF(master_secret,
+                                     "key expansion",
+                                     server_random +
+                                     client_random)[0..41]
+       client_write_MAC_secret = key_block[0..15]
+       server_write_MAC_secret = key_block[16..31]
+       client_write_key        = key_block[32..36]
+       server_write_key        = key_block[37..41]
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 22]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       final_client_write_key  = PRF(client_write_key,
+                                     "client write key",
+                                     client_random +
+                                     server_random)[0..15]
+       final_server_write_key  = PRF(server_write_key,
+                                     "server write key",
+                                     client_random +
+                                     server_random)[0..15]
+
+       iv_block                = PRF("", "IV block", client_random +
+                                     server_random)[0..15]
+       client_write_IV = iv_block[0..7]
+       server_write_IV = iv_block[8..15]
+
+7. The TLS Handshake Protocol
+
+   The TLS Handshake Protocol consists of a suite of three sub-protocols
+   which are used to allow peers to agree upon security parameters for
+   the record layer, authenticate themselves, instantiate negotiated
+   security parameters, and report error conditions to each other.
+
+   The Handshake Protocol is responsible for negotiating a session,
+   which consists of the following items:
+
+   session identifier
+       An arbitrary byte sequence chosen by the server to identify an
+       active or resumable session state.
+
+   peer certificate
+       X509v3 [X509] certificate of the peer. This element of the state
+       may be null.
+
+   compression method
+       The algorithm used to compress data prior to encryption.
+
+   cipher spec
+       Specifies the bulk data encryption algorithm (such as null, DES,
+       etc.) and a MAC algorithm (such as MD5 or SHA). It also defines
+       cryptographic attributes such as the hash_size. (See Appendix A.6
+       for formal definition)
+
+   master secret
+       48-byte secret shared between the client and server.
+
+   is resumable
+       A flag indicating whether the session can be used to initiate new
+       connections.
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 23]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   These items are then used to create security parameters for use by
+   the Record Layer when protecting application data. Many connections
+   can be instantiated using the same session through the resumption
+   feature of the TLS Handshake Protocol.
+
+7.1. Change cipher spec protocol
+
+   The change cipher spec protocol exists to signal transitions in
+   ciphering strategies. The protocol consists of a single message,
+   which is encrypted and compressed under the current (not the pending)
+   connection state. The message consists of a single byte of value 1.
+
+       struct {
+           enum { change_cipher_spec(1), (255) } type;
+       } ChangeCipherSpec;
+
+   The change cipher spec message is sent by both the client and server
+   to notify the receiving party that subsequent records will be
+   protected under the newly negotiated CipherSpec and keys. Reception
+   of this message causes the receiver to instruct the Record Layer to
+   immediately copy the read pending state into the read current state.
+   Immediately after sending this message, the sender should instruct
+   the record layer to make the write pending state the write active
+   state. (See section 6.1.) The change cipher spec message is sent
+   during the handshake after the security parameters have been agreed
+   upon, but before the verifying finished message is sent (see section
+   7.4.9).
+
+7.2. Alert protocol
+
+   One of the content types supported by the TLS Record layer is the
+   alert type. Alert messages convey the severity of the message and a
+   description of the alert. Alert messages with a level of fatal result
+   in the immediate termination of the connection. In this case, other
+   connections corresponding to the session may continue, but the
+   session identifier must be invalidated, preventing the failed session
+   from being used to establish new connections. Like other messages,
+   alert messages are encrypted and compressed, as specified by the
+   current connection state.
+
+       enum { warning(1), fatal(2), (255) } AlertLevel;
+
+       enum {
+           close_notify(0),
+           unexpected_message(10),
+           bad_record_mac(20),
+           decryption_failed(21),
+           record_overflow(22),
+
+
+
+Dierks & Allen              Standards Track                    [Page 24]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+           decompression_failure(30),
+           handshake_failure(40),
+           bad_certificate(42),
+           unsupported_certificate(43),
+           certificate_revoked(44),
+           certificate_expired(45),
+           certificate_unknown(46),
+           illegal_parameter(47),
+           unknown_ca(48),
+           access_denied(49),
+           decode_error(50),
+           decrypt_error(51),
+           export_restriction(60),
+           protocol_version(70),
+           insufficient_security(71),
+           internal_error(80),
+           user_canceled(90),
+           no_renegotiation(100),
+           (255)
+       } AlertDescription;
+
+       struct {
+           AlertLevel level;
+           AlertDescription description;
+       } Alert;
+
+7.2.1. Closure alerts
+
+   The client and the server must share knowledge that the connection is
+   ending in order to avoid a truncation attack. Either party may
+   initiate the exchange of closing messages.
+
+   close_notify
+       This message notifies the recipient that the sender will not send
+       any more messages on this connection. The session becomes
+       unresumable if any connection is terminated without proper
+       close_notify messages with level equal to warning.
+
+   Either party may initiate a close by sending a close_notify alert.
+   Any data received after a closure alert is ignored.
+
+   Each party is required to send a close_notify alert before closing
+   the write side of the connection. It is required that the other party
+   respond with a close_notify alert of its own and close down the
+   connection immediately, discarding any pending writes. It is not
+   required for the initiator of the close to wait for the responding
+   close_notify alert before closing the read side of the connection.
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 25]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   If the application protocol using TLS provides that any data may be
+   carried over the underlying transport after the TLS connection is
+   closed, the TLS implementation must receive the responding
+   close_notify alert before indicating to the application layer that
+   the TLS connection has ended. If the application protocol will not
+   transfer any additional data, but will only close the underlying
+   transport connection, then the implementation may choose to close the
+   transport without waiting for the responding close_notify. No part of
+   this standard should be taken to dictate the manner in which a usage
+   profile for TLS manages its data transport, including when
+   connections are opened or closed.
+
+   NB: It is assumed that closing a connection reliably delivers
+       pending data before destroying the transport.
+
+7.2.2. Error alerts
+
+   Error handling in the TLS Handshake protocol is very simple. When an
+   error is detected, the detecting party sends a message to the other
+   party. Upon transmission or receipt of an fatal alert message, both
+   parties immediately close the connection. Servers and clients are
+   required to forget any session-identifiers, keys, and secrets
+   associated with a failed connection. The following error alerts are
+   defined:
+
+   unexpected_message
+       An inappropriate message was received. This alert is always fatal
+       and should never be observed in communication between proper
+       implementations.
+
+   bad_record_mac
+       This alert is returned if a record is received with an incorrect
+       MAC. This message is always fatal.
+
+   decryption_failed
+       A TLSCiphertext decrypted in an invalid way: either it wasn`t an
+       even multiple of the block length or its padding values, when
+       checked, weren`t correct. This message is always fatal.
+
+   record_overflow
+       A TLSCiphertext record was received which had a length more than
+       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
+       with more than 2^14+1024 bytes. This message is always fatal.
+
+   decompression_failure
+       The decompression function received improper input (e.g. data
+       that would expand to excessive length). This message is always
+       fatal.
+
+
+
+Dierks & Allen              Standards Track                    [Page 26]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   handshake_failure
+       Reception of a handshake_failure alert message indicates that the
+       sender was unable to negotiate an acceptable set of security
+       parameters given the options available. This is a fatal error.
+
+   bad_certificate
+       A certificate was corrupt, contained signatures that did not
+       verify correctly, etc.
+
+   unsupported_certificate
+       A certificate was of an unsupported type.
+
+   certificate_revoked
+       A certificate was revoked by its signer.
+
+   certificate_expired
+       A certificate has expired or is not currently valid.
+
+   certificate_unknown
+       Some other (unspecified) issue arose in processing the
+       certificate, rendering it unacceptable.
+
+   illegal_parameter
+       A field in the handshake was out of range or inconsistent with
+       other fields. This is always fatal.
+
+   unknown_ca
+       A valid certificate chain or partial chain was received, but the
+       certificate was not accepted because the CA certificate could not
+       be located or couldn`t be matched with a known, trusted CA.  This
+       message is always fatal.
+
+   access_denied
+       A valid certificate was received, but when access control was
+       applied, the sender decided not to proceed with negotiation.
+       This message is always fatal.
+
+   decode_error
+       A message could not be decoded because some field was out of the
+       specified range or the length of the message was incorrect. This
+       message is always fatal.
+
+   decrypt_error
+       A handshake cryptographic operation failed, including being
+       unable to correctly verify a signature, decrypt a key exchange,
+       or validate a finished message.
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 27]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   export_restriction
+       A negotiation not in compliance with export restrictions was
+       detected; for example, attempting to transfer a 1024 bit
+       ephemeral RSA key for the RSA_EXPORT handshake method. This
+       message is always fatal.
+
+   protocol_version
+       The protocol version the client has attempted to negotiate is
+       recognized, but not supported. (For example, old protocol
+       versions might be avoided for security reasons). This message is
+       always fatal.
+
+   insufficient_security
+       Returned instead of handshake_failure when a negotiation has
+       failed specifically because the server requires ciphers more
+       secure than those supported by the client. This message is always
+       fatal.
+
+   internal_error
+       An internal error unrelated to the peer or the correctness of the
+       protocol makes it impossible to continue (such as a memory
+       allocation failure). This message is always fatal.
+
+   user_canceled
+       This handshake is being canceled for some reason unrelated to a
+       protocol failure. If the user cancels an operation after the
+       handshake is complete, just closing the connection by sending a
+       close_notify is more appropriate. This alert should be followed
+       by a close_notify. This message is generally a warning.
+
+   no_renegotiation
+       Sent by the client in response to a hello request or by the
+       server in response to a client hello after initial handshaking.
+       Either of these would normally lead to renegotiation; when that
+       is not appropriate, the recipient should respond with this alert;
+       at that point, the original requester can decide whether to
+       proceed with the connection. One case where this would be
+       appropriate would be where a server has spawned a process to
+       satisfy a request; the process might receive security parameters
+       (key length, authentication, etc.) at startup and it might be
+       difficult to communicate changes to these parameters after that
+       point. This message is always a warning.
+
+   For all errors where an alert level is not explicitly specified, the
+   sending party may determine at its discretion whether this is a fatal
+   error or not; if an alert with a level of warning is received, the
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 28]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   receiving party may decide at its discretion whether to treat this as
+   a fatal error or not. However, all messages which are transmitted
+   with a level of fatal must be treated as fatal messages.
+
+7.3. Handshake Protocol overview
+
+   The cryptographic parameters of the session state are produced by the
+   TLS Handshake Protocol, which operates on top of the TLS Record
+   Layer. When a TLS client and server first start communicating, they
+   agree on a protocol version, select cryptographic algorithms,
+   optionally authenticate each other, and use public-key encryption
+   techniques to generate shared secrets.
+
+   The TLS Handshake Protocol involves the following steps:
+
+     - Exchange hello messages to agree on algorithms, exchange random
+       values, and check for session resumption.
+
+     - Exchange the necessary cryptographic parameters to allow the
+       client and server to agree on a premaster secret.
+
+     - Exchange certificates and cryptographic information to allow the
+       client and server to authenticate themselves.
+
+     - Generate a master secret from the premaster secret and exchanged
+       random values.
+
+     - Provide security parameters to the record layer.
+
+     - Allow the client and server to verify that their peer has
+       calculated the same security parameters and that the handshake
+       occurred without tampering by an attacker.
+
+   Note that higher layers should not be overly reliant on TLS always
+   negotiating the strongest possible connection between two peers:
+   there are a number of ways a man in the middle attacker can attempt
+   to make two entities drop down to the least secure method they
+   support. The protocol has been designed to minimize this risk, but
+   there are still attacks available: for example, an attacker could
+   block access to the port a secure service runs on, or attempt to get
+   the peers to negotiate an unauthenticated connection. The fundamental
+   rule is that higher levels must be cognizant of what their security
+   requirements are and never transmit information over a channel less
+   secure than what they require. The TLS protocol is secure, in that
+   any cipher suite offers its promised level of security: if you
+   negotiate 3DES with a 1024 bit RSA key exchange with a host whose
+   certificate you have verified, you can expect to be that secure.
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 29]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   However, you should never send data over a link encrypted with 40 bit
+   security unless you feel that data is worth no more than the effort
+   required to break that encryption.
+
+   These goals are achieved by the handshake protocol, which can be
+   summarized as follows: The client sends a client hello message to
+   which the server must respond with a server hello message, or else a
+   fatal error will occur and the connection will fail. The client hello
+   and server hello are used to establish security enhancement
+   capabilities between client and server. The client hello and server
+   hello establish the following attributes: Protocol Version, Session
+   ID, Cipher Suite, and Compression Method. Additionally, two random
+   values are generated and exchanged: ClientHello.random and
+   ServerHello.random.
+
+   The actual key exchange uses up to four messages: the server
+   certificate, the server key exchange, the client certificate, and the
+   client key exchange. New key exchange methods can be created by
+   specifying a format for these messages and defining the use of the
+   messages to allow the client and server to agree upon a shared
+   secret. This secret should be quite long; currently defined key
+   exchange methods exchange secrets which range from 48 to 128 bytes in
+   length.
+
+   Following the hello messages, the server will send its certificate,
+   if it is to be authenticated. Additionally, a server key exchange
+   message may be sent, if it is required (e.g. if their server has no
+   certificate, or if its certificate is for signing only). If the
+   server is authenticated, it may request a certificate from the
+   client, if that is appropriate to the cipher suite selected. Now the
+   server will send the server hello done message, indicating that the
+   hello-message phase of the handshake is complete. The server will
+   then wait for a client response. If the server has sent a certificate
+   request message, the client must send the certificate message. The
+   client key exchange message is now sent, and the content of that
+   message will depend on the public key algorithm selected between the
+   client hello and the server hello. If the client has sent a
+   certificate with signing ability, a digitally-signed certificate
+   verify message is sent to explicitly verify the certificate.
+
+   At this point, a change cipher spec message is sent by the client,
+   and the client copies the pending Cipher Spec into the current Cipher
+   Spec. The client then immediately sends the finished message under
+   the new algorithms, keys, and secrets. In response, the server will
+   send its own change cipher spec message, transfer the pending to the
+   current Cipher Spec, and send its finished message under the new
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 30]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Cipher Spec. At this point, the handshake is complete and the client
+   and server may begin to exchange application layer data. (See flow
+   chart below.)
+
+      Client                                               Server
+
+      ClientHello                  -------->
+                                                      ServerHello
+                                                     Certificate*
+                                               ServerKeyExchange*
+                                              CertificateRequest*
+                                   <--------      ServerHelloDone
+      Certificate*
+      ClientKeyExchange
+      CertificateVerify*
+      [ChangeCipherSpec]
+      Finished                     -------->
+                                               [ChangeCipherSpec]
+                                   <--------             Finished
+      Application Data             <------->     Application Data
+
+             Fig. 1 - Message flow for a full handshake
+
+   * Indicates optional or situation-dependent messages that are not
+   always sent.
+
+  Note: To help avoid pipeline stalls, ChangeCipherSpec is an
+       independent TLS Protocol content type, and is not actually a TLS
+       handshake message.
+
+   When the client and server decide to resume a previous session or
+   duplicate an existing session (instead of negotiating new security
+   parameters) the message flow is as follows:
+
+   The client sends a ClientHello using the Session ID of the session to
+   be resumed. The server then checks its session cache for a match.  If
+   a match is found, and the server is willing to re-establish the
+   connection under the specified session state, it will send a
+   ServerHello with the same Session ID value. At this point, both
+   client and server must send change cipher spec messages and proceed
+   directly to finished messages. Once the re-establishment is complete,
+   the client and server may begin to exchange application layer data.
+   (See flow chart below.) If a Session ID match is not found, the
+   server generates a new session ID and the TLS client and server
+   perform a full handshake.
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 31]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+      Client                                                Server
+
+      ClientHello                   -------->
+                                                       ServerHello
+                                                [ChangeCipherSpec]
+                                    <--------             Finished
+      [ChangeCipherSpec]
+      Finished                      -------->
+      Application Data              <------->     Application Data
+
+          Fig. 2 - Message flow for an abbreviated handshake
+
+   The contents and significance of each message will be presented in
+   detail in the following sections.
+
+7.4. Handshake protocol
+
+   The TLS Handshake Protocol is one of the defined higher level clients
+   of the TLS Record Protocol. This protocol is used to negotiate the
+   secure attributes of a session. Handshake messages are supplied to
+   the TLS Record Layer, where they are encapsulated within one or more
+   TLSPlaintext structures, which are processed and transmitted as
+   specified by the current active session state.
+
+       enum {
+           hello_request(0), client_hello(1), server_hello(2),
+           certificate(11), server_key_exchange (12),
+           certificate_request(13), server_hello_done(14),
+           certificate_verify(15), client_key_exchange(16),
+           finished(20), (255)
+       } HandshakeType;
+
+       struct {
+           HandshakeType msg_type;    /* handshake type */
+           uint24 length;             /* bytes in message */
+           select (HandshakeType) {
+               case hello_request:       HelloRequest;
+               case client_hello:        ClientHello;
+               case server_hello:        ServerHello;
+               case certificate:         Certificate;
+               case server_key_exchange: ServerKeyExchange;
+               case certificate_request: CertificateRequest;
+               case server_hello_done:   ServerHelloDone;
+               case certificate_verify:  CertificateVerify;
+               case client_key_exchange: ClientKeyExchange;
+               case finished:            Finished;
+           } body;
+       } Handshake;
+
+
+
+Dierks & Allen              Standards Track                    [Page 32]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   The handshake protocol messages are presented below in the order they
+   must be sent; sending handshake messages in an unexpected order
+   results in a fatal error. Unneeded handshake messages can be omitted,
+   however. Note one exception to the ordering: the Certificate message
+   is used twice in the handshake (from server to client, then from
+   client to server), but described only in its first position. The one
+   message which is not bound by these ordering rules in the Hello
+   Request message, which can be sent at any time, but which should be
+   ignored by the client if it arrives in the middle of a handshake.
+
+7.4.1. Hello messages
+
+   The hello phase messages are used to exchange security enhancement
+   capabilities between the client and server. When a new session
+   begins, the Record Layer's connection state encryption, hash, and
+   compression algorithms are initialized to null. The current
+   connection state is used for renegotiation messages.
+
+7.4.1.1. Hello request
+
+   When this message will be sent:
+       The hello request message may be sent by the server at any time.
+
+   Meaning of this message:
+       Hello request is a simple notification that the client should
+       begin the negotiation process anew by sending a client hello
+       message when convenient. This message will be ignored by the
+       client if the client is currently negotiating a session. This
+       message may be ignored by the client if it does not wish to
+       renegotiate a session, or the client may, if it wishes, respond
+       with a no_renegotiation alert. Since handshake messages are
+       intended to have transmission precedence over application data,
+       it is expected that the negotiation will begin before no more
+       than a few records are received from the client. If the server
+       sends a hello request but does not receive a client hello in
+       response, it may close the connection with a fatal alert.
+
+   After sending a hello request, servers should not repeat the request
+   until the subsequent handshake negotiation is complete.
+
+   Structure of this message:
+       struct { } HelloRequest;
+
+ Note: This message should never be included in the message hashes which
+       are maintained throughout the handshake and used in the finished
+       messages and the certificate verify message.
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 33]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+7.4.1.2. Client hello
+
+   When this message will be sent:
+       When a client first connects to a server it is required to send
+       the client hello as its first message. The client can also send a
+       client hello in response to a hello request or on its own
+       initiative in order to renegotiate the security parameters in an
+       existing connection.
+
+       Structure of this message:
+           The client hello message includes a random structure, which is
+           used later in the protocol.
+
+           struct {
+              uint32 gmt_unix_time;
+              opaque random_bytes[28];
+           } Random;
+
+       gmt_unix_time
+       The current time and date in standard UNIX 32-bit format (seconds
+       since the midnight starting Jan 1, 1970, GMT) according to the
+       sender's internal clock. Clocks are not required to be set
+       correctly by the basic TLS Protocol; higher level or application
+       protocols may define additional requirements.
+
+   random_bytes
+       28 bytes generated by a secure random number generator.
+
+   The client hello message includes a variable length session
+   identifier. If not empty, the value identifies a session between the
+   same client and server whose security parameters the client wishes to
+   reuse. The session identifier may be from an earlier connection, this
+   connection, or another currently active connection. The second option
+   is useful if the client only wishes to update the random structures
+   and derived values of a connection, while the third option makes it
+   possible to establish several independent secure connections without
+   repeating the full handshake protocol. These independent connections
+   may occur sequentially or simultaneously; a SessionID becomes valid
+   when the handshake negotiating it completes with the exchange of
+   Finished messages and persists until removed due to aging or because
+   a fatal error was encountered on a connection associated with the
+   session. The actual contents of the SessionID are defined by the
+   server.
+
+       opaque SessionID<0..32>;
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 34]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Warning:
+       Because the SessionID is transmitted without encryption or
+       immediate MAC protection, servers must not place confidential
+       information in session identifiers or let the contents of fake
+       session identifiers cause any breach of security. (Note that the
+       content of the handshake as a whole, including the SessionID, is
+       protected by the Finished messages exchanged at the end of the
+       handshake.)
+
+   The CipherSuite list, passed from the client to the server in the
+   client hello message, contains the combinations of cryptographic
+   algorithms supported by the client in order of the client's
+   preference (favorite choice first). Each CipherSuite defines a key
+   exchange algorithm, a bulk encryption algorithm (including secret key
+   length) and a MAC algorithm. The server will select a cipher suite
+   or, if no acceptable choices are presented, return a handshake
+   failure alert and close the connection.
+
+       uint8 CipherSuite[2];    /* Cryptographic suite selector */
+
+   The client hello includes a list of compression algorithms supported
+   by the client, ordered according to the client's preference.
+
+       enum { null(0), (255) } CompressionMethod;
+
+       struct {
+           ProtocolVersion client_version;
+           Random random;
+           SessionID session_id;
+           CipherSuite cipher_suites<2..2^16-1>;
+           CompressionMethod compression_methods<1..2^8-1>;
+       } ClientHello;
+
+   client_version
+       The version of the TLS protocol by which the client wishes to
+       communicate during this session. This should be the latest
+       (highest valued) version supported by the client. For this
+       version of the specification, the version will be 3.1 (See
+       Appendix E for details about backward compatibility).
+
+   random
+       A client-generated random structure.
+
+   session_id
+       The ID of a session the client wishes to use for this connection.
+       This field should be empty if no session_id is available or the
+       client wishes to generate new security parameters.
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 35]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   cipher_suites
+       This is a list of the cryptographic options supported by the
+       client, with the client's first preference first. If the
+       session_id field is not empty (implying a session resumption
+       request) this vector must include at least the cipher_suite from
+       that session. Values are defined in Appendix A.5.
+
+   compression_methods
+       This is a list of the compression methods supported by the
+       client, sorted by client preference. If the session_id field is
+       not empty (implying a session resumption request) it must include
+       the compression_method from that session. This vector must
+       contain, and all implementations must support,
+       CompressionMethod.null. Thus, a client and server will always be
+       able to agree on a compression method.
+
+   After sending the client hello message, the client waits for a server
+   hello message. Any other handshake message returned by the server
+   except for a hello request is treated as a fatal error.
+
+   Forward compatibility note:
+       In the interests of forward compatibility, it is permitted for a
+       client hello message to include extra data after the compression
+       methods. This data must be included in the handshake hashes, but
+       must otherwise be ignored. This is the only handshake message for
+       which this is legal; for all other messages, the amount of data
+       in the message must match the description of the message
+       precisely.
+
+7.4.1.3. Server hello
+
+   When this message will be sent:
+       The server will send this message in response to a client hello
+       message when it was able to find an acceptable set of algorithms.
+       If it cannot find such a match, it will respond with a handshake
+       failure alert.
+
+   Structure of this message:
+       struct {
+           ProtocolVersion server_version;
+           Random random;
+           SessionID session_id;
+           CipherSuite cipher_suite;
+           CompressionMethod compression_method;
+       } ServerHello;
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 36]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   server_version
+       This field will contain the lower of that suggested by the client
+       in the client hello and the highest supported by the server. For
+       this version of the specification, the version is 3.1 (See
+       Appendix E for details about backward compatibility).
+
+   random
+       This structure is generated by the server and must be different
+       from (and independent of) ClientHello.random.
+
+   session_id
+       This is the identity of the session corresponding to this
+       connection. If the ClientHello.session_id was non-empty, the
+       server will look in its session cache for a match. If a match is
+       found and the server is willing to establish the new connection
+       using the specified session state, the server will respond with
+       the same value as was supplied by the client. This indicates a
+       resumed session and dictates that the parties must proceed
+       directly to the finished messages. Otherwise this field will
+       contain a different value identifying the new session. The server
+       may return an empty session_id to indicate that the session will
+       not be cached and therefore cannot be resumed. If a session is
+       resumed, it must be resumed using the same cipher suite it was
+       originally negotiated with.
+
+   cipher_suite
+       The single cipher suite selected by the server from the list in
+       ClientHello.cipher_suites. For resumed sessions this field is the
+       value from the state of the session being resumed.
+
+   compression_method
+       The single compression algorithm selected by the server from the
+       list in ClientHello.compression_methods. For resumed sessions
+       this field is the value from the resumed session state.
+
+7.4.2. Server certificate
+
+   When this message will be sent:
+       The server must send a certificate whenever the agreed-upon key
+       exchange method is not an anonymous one. This message will always
+       immediately follow the server hello message.
+
+   Meaning of this message:
+       The certificate type must be appropriate for the selected cipher
+       suite's key exchange algorithm, and is generally an X.509v3
+       certificate. It must contain a key which matches the key exchange
+       method, as follows. Unless otherwise specified, the signing
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 37]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       algorithm for the certificate must be the same as the algorithm
+       for the certificate key. Unless otherwise specified, the public
+       key may be of any length.
+
+       Key Exchange Algorithm  Certificate Key Type
+
+       RSA                     RSA public key; the certificate must
+                               allow the key to be used for encryption.
+
+       RSA_EXPORT              RSA public key of length greater than
+                               512 bits which can be used for signing,
+                               or a key of 512 bits or shorter which
+                               can be used for either encryption or
+                               signing.
+
+       DHE_DSS                 DSS public key.
+
+       DHE_DSS_EXPORT          DSS public key.
+
+       DHE_RSA                 RSA public key which can be used for
+                               signing.
+
+       DHE_RSA_EXPORT          RSA public key which can be used for
+                               signing.
+
+       DH_DSS                  Diffie-Hellman key. The algorithm used
+                               to sign the certificate should be DSS.
+
+       DH_RSA                  Diffie-Hellman key. The algorithm used
+                               to sign the certificate should be RSA.
+
+   All certificate profiles, key and cryptographic formats are defined
+   by the IETF PKIX working group [PKIX]. When a key usage extension is
+   present, the digitalSignature bit must be set for the key to be
+   eligible for signing, as described above, and the keyEncipherment bit
+   must be present to allow encryption, as described above. The
+   keyAgreement bit must be set on Diffie-Hellman certificates.
+
+   As CipherSuites which specify new key exchange methods are specified
+   for the TLS Protocol, they will imply certificate format and the
+   required encoded keying information.
+
+   Structure of this message:
+       opaque ASN.1Cert<1..2^24-1>;
+
+       struct {
+           ASN.1Cert certificate_list<0..2^24-1>;
+       } Certificate;
+
+
+
+Dierks & Allen              Standards Track                    [Page 38]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   certificate_list
+       This is a sequence (chain) of X.509v3 certificates. The sender's
+       certificate must come first in the list. Each following
+       certificate must directly certify the one preceding it. Because
+       certificate validation requires that root keys be distributed
+       independently, the self-signed certificate which specifies the
+       root certificate authority may optionally be omitted from the
+       chain, under the assumption that the remote end must already
+       possess it in order to validate it in any case.
+
+   The same message type and structure will be used for the client's
+   response to a certificate request message. Note that a client may
+   send no certificates if it does not have an appropriate certificate
+   to send in response to the server's authentication request.
+
+ Note: PKCS #7 [PKCS7] is not used as the format for the certificate
+       vector because PKCS #6 [PKCS6] extended certificates are not
+       used. Also PKCS #7 defines a SET rather than a SEQUENCE, making
+       the task of parsing the list more difficult.
+
+7.4.3. Server key exchange message
+
+   When this message will be sent:
+       This message will be sent immediately after the server
+       certificate message (or the server hello message, if this is an
+       anonymous negotiation).
+
+       The server key exchange message is sent by the server only when
+       the server certificate message (if sent) does not contain enough
+       data to allow the client to exchange a premaster secret. This is
+       true for the following key exchange methods:
+
+           RSA_EXPORT (if the public key in the server certificate is
+           longer than 512 bits)
+           DHE_DSS
+           DHE_DSS_EXPORT
+           DHE_RSA
+           DHE_RSA_EXPORT
+           DH_anon
+
+       It is not legal to send the server key exchange message for the
+       following key exchange methods:
+
+           RSA
+           RSA_EXPORT (when the public key in the server certificate is
+           less than or equal to 512 bits in length)
+           DH_DSS
+           DH_RSA
+
+
+
+Dierks & Allen              Standards Track                    [Page 39]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Meaning of this message:
+       This message conveys cryptographic information to allow the
+       client to communicate the premaster secret: either an RSA public
+       key to encrypt the premaster secret with, or a Diffie-Hellman
+       public key with which the client can complete a key exchange
+       (with the result being the premaster secret.)
+
+   As additional CipherSuites are defined for TLS which include new key
+   exchange algorithms, the server key exchange message will be sent if
+   and only if the certificate type associated with the key exchange
+   algorithm does not provide enough information for the client to
+   exchange a premaster secret.
+
+ Note: According to current US export law, RSA moduli larger than 512
+       bits may not be used for key exchange in software exported from
+       the US. With this message, the larger RSA keys encoded in
+       certificates may be used to sign temporary shorter RSA keys for
+       the RSA_EXPORT key exchange method.
+
+   Structure of this message:
+       enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
+
+       struct {
+           opaque rsa_modulus<1..2^16-1>;
+           opaque rsa_exponent<1..2^16-1>;
+       } ServerRSAParams;
+
+       rsa_modulus
+           The modulus of the server's temporary RSA key.
+
+       rsa_exponent
+           The public exponent of the server's temporary RSA key.
+
+       struct {
+           opaque dh_p<1..2^16-1>;
+           opaque dh_g<1..2^16-1>;
+           opaque dh_Ys<1..2^16-1>;
+       } ServerDHParams;     /* Ephemeral DH parameters */
+
+       dh_p
+           The prime modulus used for the Diffie-Hellman operation.
+
+       dh_g
+           The generator used for the Diffie-Hellman operation.
+
+       dh_Ys
+           The server's Diffie-Hellman public value (g^X mod p).
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 40]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       struct {
+           select (KeyExchangeAlgorithm) {
+               case diffie_hellman:
+                   ServerDHParams params;
+                   Signature signed_params;
+               case rsa:
+                   ServerRSAParams params;
+                   Signature signed_params;
+           };
+       } ServerKeyExchange;
+
+       params
+           The server's key exchange parameters.
+
+       signed_params
+           For non-anonymous key exchanges, a hash of the corresponding
+           params value, with the signature appropriate to that hash
+           applied.
+
+       md5_hash
+           MD5(ClientHello.random + ServerHello.random + ServerParams);
+
+       sha_hash
+           SHA(ClientHello.random + ServerHello.random + ServerParams);
+
+       enum { anonymous, rsa, dsa } SignatureAlgorithm;
+
+       select (SignatureAlgorithm)
+       {   case anonymous: struct { };
+           case rsa:
+               digitally-signed struct {
+                   opaque md5_hash[16];
+                   opaque sha_hash[20];
+               };
+           case dsa:
+               digitally-signed struct {
+                   opaque sha_hash[20];
+               };
+       } Signature;
+
+7.4.4. Certificate request
+
+   When this message will be sent:
+       A non-anonymous server can optionally request a certificate from
+       the client, if appropriate for the selected cipher suite. This
+       message, if sent, will immediately follow the Server Key Exchange
+       message (if it is sent; otherwise, the Server Certificate
+       message).
+
+
+
+Dierks & Allen              Standards Track                    [Page 41]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Structure of this message:
+       enum {
+           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
+           (255)
+       } ClientCertificateType;
+
+       opaque DistinguishedName<1..2^16-1>;
+
+       struct {
+           ClientCertificateType certificate_types<1..2^8-1>;
+           DistinguishedName certificate_authorities<3..2^16-1>;
+       } CertificateRequest;
+
+       certificate_types
+              This field is a list of the types of certificates requested,
+              sorted in order of the server's preference.
+
+       certificate_authorities
+           A list of the distinguished names of acceptable certificate
+           authorities. These distinguished names may specify a desired
+           distinguished name for a root CA or for a subordinate CA;
+           thus, this message can be used both to describe known roots
+           and a desired authorization space.
+
+ Note: DistinguishedName is derived from [X509].
+
+ Note: It is a fatal handshake_failure alert for an anonymous server to
+       request client identification.
+
+7.4.5. Server hello done
+
+   When this message will be sent:
+       The server hello done message is sent by the server to indicate
+       the end of the server hello and associated messages. After
+       sending this message the server will wait for a client response.
+
+   Meaning of this message:
+       This message means that the server is done sending messages to
+       support the key exchange, and the client can proceed with its
+       phase of the key exchange.
+
+       Upon receipt of the server hello done message the client should
+       verify that the server provided a valid certificate if required
+       and check that the server hello parameters are acceptable.
+
+   Structure of this message:
+       struct { } ServerHelloDone;
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 42]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+7.4.6. Client certificate
+
+   When this message will be sent:
+       This is the first message the client can send after receiving a
+       server hello done message. This message is only sent if the
+       server requests a certificate. If no suitable certificate is
+       available, the client should send a certificate message
+       containing no certificates. If client authentication is required
+       by the server for the handshake to continue, it may respond with
+       a fatal handshake failure alert. Client certificates are sent
+       using the Certificate structure defined in Section 7.4.2.
+
+ Note: When using a static Diffie-Hellman based key exchange method
+       (DH_DSS or DH_RSA), if client authentication is requested, the
+       Diffie-Hellman group and generator encoded in the client's
+       certificate must match the server specified Diffie-Hellman
+       parameters if the client's parameters are to be used for the key
+       exchange.
+
+7.4.7. Client key exchange message
+
+   When this message will be sent:
+       This message is always sent by the client. It will immediately
+       follow the client certificate message, if it is sent. Otherwise
+       it will be the first message sent by the client after it receives
+       the server hello done message.
+
+   Meaning of this message:
+       With this message, the premaster secret is set, either though
+       direct transmission of the RSA-encrypted secret, or by the
+       transmission of Diffie-Hellman parameters which will allow each
+       side to agree upon the same premaster secret. When the key
+       exchange method is DH_RSA or DH_DSS, client certification has
+       been requested, and the client was able to respond with a
+       certificate which contained a Diffie-Hellman public key whose
+       parameters (group and generator) matched those specified by the
+       server in its certificate, this message will not contain any
+       data.
+
+   Structure of this message:
+       The choice of messages depends on which key exchange method has
+       been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
+       definition.
+
+       struct {
+           select (KeyExchangeAlgorithm) {
+               case rsa: EncryptedPreMasterSecret;
+               case diffie_hellman: ClientDiffieHellmanPublic;
+
+
+
+Dierks & Allen              Standards Track                    [Page 43]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+           } exchange_keys;
+       } ClientKeyExchange;
+
+7.4.7.1. RSA encrypted premaster secret message
+
+   Meaning of this message:
+       If RSA is being used for key agreement and authentication, the
+       client generates a 48-byte premaster secret, encrypts it using
+       the public key from the server's certificate or the temporary RSA
+       key provided in a server key exchange message, and sends the
+       result in an encrypted premaster secret message. This structure
+       is a variant of the client key exchange message, not a message in
+       itself.
+
+   Structure of this message:
+       struct {
+           ProtocolVersion client_version;
+           opaque random[46];
+       } PreMasterSecret;
+
+       client_version
+           The latest (newest) version supported by the client. This is
+           used to detect version roll-back attacks. Upon receiving the
+           premaster secret, the server should check that this value
+           matches the value transmitted by the client in the client
+           hello message.
+
+       random
+           46 securely-generated random bytes.
+
+       struct {
+           public-key-encrypted PreMasterSecret pre_master_secret;
+       } EncryptedPreMasterSecret;
+
+ Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used
+       to attack a TLS server which is using PKCS#1 encoded RSA. The
+       attack takes advantage of the fact that by failing in different
+       ways, a TLS server can be coerced into revealing whether a
+       particular message, when decrypted, is properly PKCS#1 formatted
+       or not.
+
+       The best way to avoid vulnerability to this attack is to treat
+       incorrectly formatted messages in a manner indistinguishable from
+       correctly formatted RSA blocks. Thus, when it receives an
+       incorrectly formatted RSA block, a server should generate a
+       random 48-byte value and proceed using it as the premaster
+       secret. Thus, the server will act identically whether the
+       received RSA block is correctly encoded or not.
+
+
+
+Dierks & Allen              Standards Track                    [Page 44]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       pre_master_secret
+           This random value is generated by the client and is used to
+           generate the master secret, as specified in Section 8.1.
+
+7.4.7.2. Client Diffie-Hellman public value
+
+   Meaning of this message:
+       This structure conveys the client's Diffie-Hellman public value
+       (Yc) if it was not already included in the client's certificate.
+       The encoding used for Yc is determined by the enumerated
+       PublicValueEncoding. This structure is a variant of the client
+       key exchange message, not a message in itself.
+
+   Structure of this message:
+       enum { implicit, explicit } PublicValueEncoding;
+
+       implicit
+           If the client certificate already contains a suitable
+           Diffie-Hellman key, then Yc is implicit and does not need to
+           be sent again. In this case, the Client Key Exchange message
+           will be sent, but will be empty.
+
+       explicit
+           Yc needs to be sent.
+
+       struct {
+           select (PublicValueEncoding) {
+               case implicit: struct { };
+               case explicit: opaque dh_Yc<1..2^16-1>;
+           } dh_public;
+       } ClientDiffieHellmanPublic;
+
+       dh_Yc
+           The client's Diffie-Hellman public value (Yc).
+
+7.4.8. Certificate verify
+
+   When this message will be sent:
+       This message is used to provide explicit verification of a client
+       certificate. This message is only sent following a client
+       certificate that has signing capability (i.e. all certificates
+       except those containing fixed Diffie-Hellman parameters). When
+       sent, it will immediately follow the client key exchange message.
+
+   Structure of this message:
+       struct {
+            Signature signature;
+       } CertificateVerify;
+
+
+
+Dierks & Allen              Standards Track                    [Page 45]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       The Signature type is defined in 7.4.3.
+
+       CertificateVerify.signature.md5_hash
+           MD5(handshake_messages);
+
+       Certificate.signature.sha_hash
+           SHA(handshake_messages);
+
+   Here handshake_messages refers to all handshake messages sent or
+   received starting at client hello up to but not including this
+   message, including the type and length fields of the handshake
+   messages. This is the concatenation of all the Handshake structures
+   as defined in 7.4 exchanged thus far.
+
+7.4.9. Finished
+
+   When this message will be sent:
+       A finished message is always sent immediately after a change
+       cipher spec message to verify that the key exchange and
+       authentication processes were successful. It is essential that a
+       change cipher spec message be received between the other
+       handshake messages and the Finished message.
+
+   Meaning of this message:
+       The finished message is the first protected with the just-
+       negotiated algorithms, keys, and secrets. Recipients of finished
+       messages must verify that the contents are correct.  Once a side
+       has sent its Finished message and received and validated the
+       Finished message from its peer, it may begin to send and receive
+       application data over the connection.
+
+       struct {
+           opaque verify_data[12];
+       } Finished;
+
+       verify_data
+           PRF(master_secret, finished_label, MD5(handshake_messages) +
+           SHA-1(handshake_messages)) [0..11];
+
+       finished_label
+           For Finished messages sent by the client, the string "client
+           finished". For Finished messages sent by the server, the
+           string "server finished".
+
+       handshake_messages
+           All of the data from all handshake messages up to but not
+           including this message. This is only data visible at the
+           handshake layer and does not include record layer headers.
+
+
+
+Dierks & Allen              Standards Track                    [Page 46]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+           This is the concatenation of all the Handshake structures as
+           defined in 7.4 exchanged thus far.
+
+   It is a fatal error if a finished message is not preceded by a change
+   cipher spec message at the appropriate point in the handshake.
+
+   The hash contained in finished messages sent by the server
+   incorporate Sender.server; those sent by the client incorporate
+   Sender.client. The value handshake_messages includes all handshake
+   messages starting at client hello up to, but not including, this
+   finished message. This may be different from handshake_messages in
+   Section 7.4.8 because it would include the certificate verify message
+   (if sent). Also, the handshake_messages for the finished message sent
+   by the client will be different from that for the finished message
+   sent by the server, because the one which is sent second will include
+   the prior one.
+
+ Note: Change cipher spec messages, alerts and any other record types
+       are not handshake messages and are not included in the hash
+       computations. Also, Hello Request messages are omitted from
+       handshake hashes.
+
+8. Cryptographic computations
+
+   In order to begin connection protection, the TLS Record Protocol
+   requires specification of a suite of algorithms, a master secret, and
+   the client and server random values. The authentication, encryption,
+   and MAC algorithms are determined by the cipher_suite selected by the
+   server and revealed in the server hello message. The compression
+   algorithm is negotiated in the hello messages, and the random values
+   are exchanged in the hello messages. All that remains is to calculate
+   the master secret.
+
+8.1. Computing the master secret
+
+   For all key exchange methods, the same algorithm is used to convert
+   the pre_master_secret into the master_secret. The pre_master_secret
+   should be deleted from memory once the master_secret has been
+   computed.
+
+       master_secret = PRF(pre_master_secret, "master secret",
+                           ClientHello.random + ServerHello.random)
+       [0..47];
+
+   The master secret is always exactly 48 bytes in length. The length of
+   the premaster secret will vary depending on key exchange method.
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 47]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+8.1.1. RSA
+
+   When RSA is used for server authentication and key exchange, a 48-
+   byte pre_master_secret is generated by the client, encrypted under
+   the server's public key, and sent to the server. The server uses its
+   private key to decrypt the pre_master_secret. Both parties then
+   convert the pre_master_secret into the master_secret, as specified
+   above.
+
+   RSA digital signatures are performed using PKCS #1 [PKCS1] block type
+   1. RSA public key encryption is performed using PKCS #1 block type 2.
+
+8.1.2. Diffie-Hellman
+
+   A conventional Diffie-Hellman computation is performed. The
+   negotiated key (Z) is used as the pre_master_secret, and is converted
+   into the master_secret, as specified above.
+
+ Note: Diffie-Hellman parameters are specified by the server, and may
+       be either ephemeral or contained within the server's certificate.
+
+9. Mandatory Cipher Suites
+
+   In the absence of an application profile standard specifying
+   otherwise, a TLS compliant application MUST implement the cipher
+   suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
+
+10. Application data protocol
+
+   Application data messages are carried by the Record Layer and are
+   fragmented, compressed and encrypted based on the current connection
+   state. The messages are treated as transparent data to the record
+   layer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 48]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+A. Protocol constant values
+
+   This section describes protocol types and constants.
+
+A.1. Record layer
+
+    struct {
+        uint8 major, minor;
+    } ProtocolVersion;
+
+    ProtocolVersion version = { 3, 1 };     /* TLS v1.0 */
+
+    enum {
+        change_cipher_spec(20), alert(21), handshake(22),
+        application_data(23), (255)
+    } ContentType;
+
+    struct {
+        ContentType type;
+        ProtocolVersion version;
+        uint16 length;
+        opaque fragment[TLSPlaintext.length];
+    } TLSPlaintext;
+
+    struct {
+        ContentType type;
+        ProtocolVersion version;
+        uint16 length;
+        opaque fragment[TLSCompressed.length];
+    } TLSCompressed;
+
+    struct {
+        ContentType type;
+        ProtocolVersion version;
+        uint16 length;
+        select (CipherSpec.cipher_type) {
+            case stream: GenericStreamCipher;
+            case block:  GenericBlockCipher;
+        } fragment;
+    } TLSCiphertext;
+
+    stream-ciphered struct {
+        opaque content[TLSCompressed.length];
+        opaque MAC[CipherSpec.hash_size];
+    } GenericStreamCipher;
+
+    block-ciphered struct {
+        opaque content[TLSCompressed.length];
+
+
+
+Dierks & Allen              Standards Track                    [Page 49]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+        opaque MAC[CipherSpec.hash_size];
+        uint8 padding[GenericBlockCipher.padding_length];
+        uint8 padding_length;
+    } GenericBlockCipher;
+
+A.2. Change cipher specs message
+
+    struct {
+        enum { change_cipher_spec(1), (255) } type;
+    } ChangeCipherSpec;
+
+A.3. Alert messages
+
+    enum { warning(1), fatal(2), (255) } AlertLevel;
+
+        enum {
+            close_notify(0),
+            unexpected_message(10),
+            bad_record_mac(20),
+            decryption_failed(21),
+            record_overflow(22),
+            decompression_failure(30),
+            handshake_failure(40),
+            bad_certificate(42),
+            unsupported_certificate(43),
+            certificate_revoked(44),
+            certificate_expired(45),
+            certificate_unknown(46),
+            illegal_parameter(47),
+            unknown_ca(48),
+            access_denied(49),
+            decode_error(50),
+            decrypt_error(51),
+            export_restriction(60),
+            protocol_version(70),
+            insufficient_security(71),
+            internal_error(80),
+            user_canceled(90),
+            no_renegotiation(100),
+            (255)
+        } AlertDescription;
+
+    struct {
+        AlertLevel level;
+        AlertDescription description;
+    } Alert;
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 50]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+A.4. Handshake protocol
+
+    enum {
+        hello_request(0), client_hello(1), server_hello(2),
+        certificate(11), server_key_exchange (12),
+        certificate_request(13), server_hello_done(14),
+        certificate_verify(15), client_key_exchange(16),
+        finished(20), (255)
+    } HandshakeType;
+
+    struct {
+        HandshakeType msg_type;
+        uint24 length;
+        select (HandshakeType) {
+            case hello_request:       HelloRequest;
+            case client_hello:        ClientHello;
+            case server_hello:        ServerHello;
+            case certificate:         Certificate;
+            case server_key_exchange: ServerKeyExchange;
+            case certificate_request: CertificateRequest;
+            case server_hello_done:   ServerHelloDone;
+            case certificate_verify:  CertificateVerify;
+            case client_key_exchange: ClientKeyExchange;
+            case finished:            Finished;
+        } body;
+    } Handshake;
+
+A.4.1. Hello messages
+
+    struct { } HelloRequest;
+
+    struct {
+        uint32 gmt_unix_time;
+        opaque random_bytes[28];
+    } Random;
+
+    opaque SessionID<0..32>;
+
+    uint8 CipherSuite[2];
+
+    enum { null(0), (255) } CompressionMethod;
+
+    struct {
+        ProtocolVersion client_version;
+        Random random;
+        SessionID session_id;
+        CipherSuite cipher_suites<2..2^16-1>;
+        CompressionMethod compression_methods<1..2^8-1>;
+
+
+
+Dierks & Allen              Standards Track                    [Page 51]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+    } ClientHello;
+
+    struct {
+        ProtocolVersion server_version;
+        Random random;
+        SessionID session_id;
+        CipherSuite cipher_suite;
+        CompressionMethod compression_method;
+    } ServerHello;
+
+A.4.2. Server authentication and key exchange messages
+
+    opaque ASN.1Cert<2^24-1>;
+
+    struct {
+        ASN.1Cert certificate_list<1..2^24-1>;
+    } Certificate;
+
+    enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
+
+    struct {
+        opaque RSA_modulus<1..2^16-1>;
+        opaque RSA_exponent<1..2^16-1>;
+    } ServerRSAParams;
+
+    struct {
+        opaque DH_p<1..2^16-1>;
+        opaque DH_g<1..2^16-1>;
+        opaque DH_Ys<1..2^16-1>;
+    } ServerDHParams;
+
+    struct {
+        select (KeyExchangeAlgorithm) {
+            case diffie_hellman:
+                ServerDHParams params;
+                Signature signed_params;
+            case rsa:
+                ServerRSAParams params;
+                Signature signed_params;
+        };
+    } ServerKeyExchange;
+
+    enum { anonymous, rsa, dsa } SignatureAlgorithm;
+
+    select (SignatureAlgorithm)
+    {   case anonymous: struct { };
+        case rsa:
+            digitally-signed struct {
+
+
+
+Dierks & Allen              Standards Track                    [Page 52]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+                opaque md5_hash[16];
+                opaque sha_hash[20];
+            };
+        case dsa:
+            digitally-signed struct {
+                opaque sha_hash[20];
+            };
+    } Signature;
+
+    enum {
+        rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
+        (255)
+    } ClientCertificateType;
+
+    opaque DistinguishedName<1..2^16-1>;
+
+    struct {
+        ClientCertificateType certificate_types<1..2^8-1>;
+        DistinguishedName certificate_authorities<3..2^16-1>;
+    } CertificateRequest;
+
+    struct { } ServerHelloDone;
+
+A.4.3. Client authentication and key exchange messages
+
+    struct {
+        select (KeyExchangeAlgorithm) {
+            case rsa: EncryptedPreMasterSecret;
+            case diffie_hellman: DiffieHellmanClientPublicValue;
+        } exchange_keys;
+    } ClientKeyExchange;
+
+    struct {
+        ProtocolVersion client_version;
+        opaque random[46];
+
+    } PreMasterSecret;
+
+    struct {
+        public-key-encrypted PreMasterSecret pre_master_secret;
+    } EncryptedPreMasterSecret;
+
+    enum { implicit, explicit } PublicValueEncoding;
+
+    struct {
+        select (PublicValueEncoding) {
+            case implicit: struct {};
+            case explicit: opaque DH_Yc<1..2^16-1>;
+
+
+
+Dierks & Allen              Standards Track                    [Page 53]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+        } dh_public;
+    } ClientDiffieHellmanPublic;
+
+    struct {
+        Signature signature;
+    } CertificateVerify;
+
+A.4.4. Handshake finalization message
+
+    struct {
+        opaque verify_data[12];
+    } Finished;
+
+A.5. The CipherSuite
+
+   The following values define the CipherSuite codes used in the client
+   hello and server hello messages.
+
+   A CipherSuite defines a cipher specification supported in TLS Version
+   1.0.
+
+   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
+   TLS connection during the first handshake on that channel, but must
+   not be negotiated, as it provides no more protection than an
+   unsecured connection.
+
+    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };
+
+   The following CipherSuite definitions require that the server provide
+   an RSA certificate that can be used for key exchange. The server may
+   request either an RSA or a DSS signature-capable certificate in the
+   certificate request message.
+
+    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
+    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
+    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
+    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
+    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
+    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
+    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
+    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
+    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
+    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };
+
+   The following CipherSuite definitions are used for server-
+   authenticated (and optionally client-authenticated) Diffie-Hellman.
+   DH denotes cipher suites in which the server's certificate contains
+   the Diffie-Hellman parameters signed by the certificate authority
+
+
+
+Dierks & Allen              Standards Track                    [Page 54]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
+   parameters are signed by a DSS or RSA certificate, which has been
+   signed by the CA. The signing algorithm used is specified after the
+   DH or DHE parameter. The server can request an RSA or DSS signature-
+   capable certificate from the client for client authentication or it
+   may request a Diffie-Hellman certificate. Any Diffie-Hellman
+   certificate provided by the client must use the parameters (group and
+   generator) described by the server.
+
+    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
+    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
+    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
+    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
+    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
+    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
+    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
+    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
+    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
+    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
+    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
+    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };
+
+   The following cipher suites are used for completely anonymous
+   Diffie-Hellman communications in which neither party is
+   authenticated. Note that this mode is vulnerable to man-in-the-middle
+   attacks and is therefore deprecated.
+
+    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
+    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00,0x18 };
+    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
+    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00,0x1A };
+    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };
+
+ Note: All cipher suites whose first byte is 0xFF are considered
+       private and can be used for defining local/experimental
+       algorithms. Interoperability of such types is a local matter.
+
+ Note: Additional cipher suites can be registered by publishing an RFC
+       which specifies the cipher suites, including the necessary TLS
+       protocol information, including message encoding, premaster
+       secret derivation, symmetric encryption and MAC calculation and
+       appropriate reference information for the algorithms involved.
+       The RFC editor's office may, at its discretion, choose to publish
+       specifications for cipher suites which are not completely
+       described (e.g., for classified algorithms) if it finds the
+       specification to be of technical interest and completely
+       specified.
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 55]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+ Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
+       reserved to avoid collision with Fortezza-based cipher suites in
+       SSL 3.
+
+A.6. The Security Parameters
+
+   These security parameters are determined by the TLS Handshake
+   Protocol and provided as parameters to the TLS Record Layer in order
+   to initialize a connection state. SecurityParameters includes:
+
+       enum { null(0), (255) } CompressionMethod;
+
+       enum { server, client } ConnectionEnd;
+
+       enum { null, rc4, rc2, des, 3des, des40, idea }
+       BulkCipherAlgorithm;
+
+       enum { stream, block } CipherType;
+
+       enum { true, false } IsExportable;
+
+       enum { null, md5, sha } MACAlgorithm;
+
+   /* The algorithms specified in CompressionMethod,
+   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
+
+       struct {
+           ConnectionEnd entity;
+           BulkCipherAlgorithm bulk_cipher_algorithm;
+           CipherType cipher_type;
+           uint8 key_size;
+           uint8 key_material_length;
+           IsExportable is_exportable;
+           MACAlgorithm mac_algorithm;
+           uint8 hash_size;
+           CompressionMethod compression_algorithm;
+           opaque master_secret[48];
+           opaque client_random[32];
+           opaque server_random[32];
+       } SecurityParameters;
+
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 56]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+B. Glossary
+
+   application protocol
+       An application protocol is a protocol that normally layers
+       directly on top of the transport layer (e.g., TCP/IP). Examples
+       include HTTP, TELNET, FTP, and SMTP.
+
+   asymmetric cipher
+       See public key cryptography.
+
+   authentication
+       Authentication is the ability of one entity to determine the
+       identity of another entity.
+
+   block cipher
+       A block cipher is an algorithm that operates on plaintext in
+       groups of bits, called blocks. 64 bits is a common block size.
+
+   bulk cipher
+       A symmetric encryption algorithm used to encrypt large quantities
+       of data.
+
+   cipher block chaining (CBC)
+       CBC is a mode in which every plaintext block encrypted with a
+       block cipher is first exclusive-ORed with the previous ciphertext
+       block (or, in the case of the first block, with the
+       initialization vector). For decryption, every block is first
+       decrypted, then exclusive-ORed with the previous ciphertext block
+       (or IV).
+
+   certificate
+       As part of the X.509 protocol (a.k.a. ISO Authentication
+       framework), certificates are assigned by a trusted Certificate
+       Authority and provide a strong binding between a party's identity
+       or some other attributes and its public key.
+
+   client
+       The application entity that initiates a TLS connection to a
+       server. This may or may not imply that the client initiated the
+       underlying transport connection. The primary operational
+       difference between the server and client is that the server is
+       generally authenticated, while the client is only optionally
+       authenticated.
+
+   client write key
+       The key used to encrypt data written by the client.
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 57]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   client write MAC secret
+       The secret data used to authenticate data written by the client.
+
+   connection
+       A connection is a transport (in the OSI layering model
+       definition) that provides a suitable type of service. For TLS,
+       such connections are peer to peer relationships. The connections
+       are transient. Every connection is associated with one session.
+
+   Data Encryption Standard
+       DES is a very widely used symmetric encryption algorithm. DES is
+       a block cipher with a 56 bit key and an 8 byte block size. Note
+       that in TLS, for key generation purposes, DES is treated as
+       having an 8 byte key length (64 bits), but it still only provides
+       56 bits of protection. (The low bit of each key byte is presumed
+       to be set to produce odd parity in that key byte.) DES can also
+       be operated in a mode where three independent keys and three
+       encryptions are used for each block of data; this uses 168 bits
+       of key (24 bytes in the TLS key generation method) and provides
+       the equivalent of 112 bits of security. [DES], [3DES]
+
+   Digital Signature Standard (DSS)
+       A standard for digital signing, including the Digital Signing
+       Algorithm, approved by the National Institute of Standards and
+       Technology, defined in NIST FIPS PUB 186, "Digital Signature
+       Standard," published May, 1994 by the U.S. Dept. of Commerce.
+       [DSS]
+
+   digital signatures
+       Digital signatures utilize public key cryptography and one-way
+       hash functions to produce a signature of the data that can be
+       authenticated, and is difficult to forge or repudiate.
+
+   handshake
+       An initial negotiation between client and server that establishes
+       the parameters of their transactions.
+
+   Initialization Vector (IV)
+       When a block cipher is used in CBC mode, the initialization
+       vector is exclusive-ORed with the first plaintext block prior to
+       encryption.
+
+   IDEA
+       A 64-bit block cipher designed by Xuejia Lai and James Massey.
+       [IDEA]
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 58]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Message Authentication Code (MAC)
+       A Message Authentication Code is a one-way hash computed from a
+       message and some secret data. It is difficult to forge without
+       knowing the secret data. Its purpose is to detect if the message
+       has been altered.
+
+   master secret
+       Secure secret data used for generating encryption keys, MAC
+       secrets, and IVs.
+
+   MD5
+       MD5 is a secure hashing function that converts an arbitrarily
+       long data stream into a digest of fixed size (16 bytes). [MD5]
+
+   public key cryptography
+       A class of cryptographic techniques employing two-key ciphers.
+       Messages encrypted with the public key can only be decrypted with
+       the associated private key. Conversely, messages signed with the
+       private key can be verified with the public key.
+
+   one-way hash function
+       A one-way transformation that converts an arbitrary amount of
+       data into a fixed-length hash. It is computationally hard to
+       reverse the transformation or to find collisions. MD5 and SHA are
+       examples of one-way hash functions.
+
+   RC2
+       A block cipher developed by Ron Rivest at RSA Data Security, Inc.
+       [RSADSI] described in [RC2].
+
+   RC4
+       A stream cipher licensed by RSA Data Security [RSADSI]. A
+       compatible cipher is described in [RC4].
+
+   RSA
+       A very widely used public-key algorithm that can be used for
+       either encryption or digital signing. [RSA]
+
+   salt
+       Non-secret random data used to make export encryption keys resist
+       precomputation attacks.
+
+   server
+       The server is the application entity that responds to requests
+       for connections from clients. See also under client.
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 59]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   session
+       A TLS session is an association between a client and a server.
+       Sessions are created by the handshake protocol. Sessions define a
+       set of cryptographic security parameters, which can be shared
+       among multiple connections. Sessions are used to avoid the
+       expensive negotiation of new security parameters for each
+       connection.
+
+   session identifier
+       A session identifier is a value generated by a server that
+       identifies a particular session.
+
+   server write key
+       The key used to encrypt data written by the server.
+
+   server write MAC secret
+       The secret data used to authenticate data written by the server.
+
+   SHA
+       The Secure Hash Algorithm is defined in FIPS PUB 180-1. It
+       produces a 20-byte output. Note that all references to SHA
+       actually use the modified SHA-1 algorithm. [SHA]
+
+   SSL
+       Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
+       SSL Version 3.0
+
+   stream cipher
+       An encryption algorithm that converts a key into a
+       cryptographically-strong keystream, which is then exclusive-ORed
+       with the plaintext.
+
+   symmetric cipher
+       See bulk cipher.
+
+   Transport Layer Security (TLS)
+       This protocol; also, the Transport Layer Security working group
+       of the Internet Engineering Task Force (IETF). See "Comments" at
+       the end of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 60]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+C. CipherSuite definitions
+
+CipherSuite                      Is       Key          Cipher      Hash
+                             Exportable Exchange
+
+TLS_NULL_WITH_NULL_NULL               * NULL           NULL        NULL
+TLS_RSA_WITH_NULL_MD5                 * RSA            NULL         MD5
+TLS_RSA_WITH_NULL_SHA                 * RSA            NULL         SHA
+TLS_RSA_EXPORT_WITH_RC4_40_MD5        * RSA_EXPORT     RC4_40       MD5
+TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
+TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
+TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5    * RSA_EXPORT     RC2_CBC_40   MD5
+TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
+TLS_RSA_EXPORT_WITH_DES40_CBC_SHA     * RSA_EXPORT     DES40_CBC    SHA
+TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
+TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
+TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA  * DH_DSS_EXPORT  DES40_CBC    SHA
+TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
+TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
+TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA  * DH_RSA_EXPORT  DES40_CBC    SHA
+TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
+TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
+TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC    SHA
+TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
+TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
+TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC    SHA
+TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
+TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
+TLS_DH_anon_EXPORT_WITH_RC4_40_MD5    * DH_anon_EXPORT RC4_40       MD5
+TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
+TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA   DH_anon        DES40_CBC    SHA
+TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
+TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
+
+
+   * Indicates IsExportable is True
+
+      Key
+      Exchange
+      Algorithm       Description                        Key size limit
+
+      DHE_DSS         Ephemeral DH with DSS signatures   None
+      DHE_DSS_EXPORT  Ephemeral DH with DSS signatures   DH = 512 bits
+      DHE_RSA         Ephemeral DH with RSA signatures   None
+      DHE_RSA_EXPORT  Ephemeral DH with RSA signatures   DH = 512 bits,
+                                                         RSA = none
+      DH_anon         Anonymous DH, no signatures        None
+      DH_anon_EXPORT  Anonymous DH, no signatures        DH = 512 bits
+
+
+
+Dierks & Allen              Standards Track                    [Page 61]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+      DH_DSS          DH with DSS-based certificates     None
+      DH_DSS_EXPORT   DH with DSS-based certificates     DH = 512 bits
+      DH_RSA          DH with RSA-based certificates     None
+      DH_RSA_EXPORT   DH with RSA-based certificates     DH = 512 bits,
+                                                         RSA = none
+      NULL            No key exchange                    N/A
+      RSA             RSA key exchange                   None
+      RSA_EXPORT      RSA key exchange                   RSA = 512 bits
+
+   Key size limit
+       The key size limit gives the size of the largest public key that
+       can be legally used for encryption in cipher suites that are
+       exportable.
+
+                         Key      Expanded   Effective   IV    Block
+    Cipher       Type  Material Key Material  Key Bits  Size   Size
+
+    NULL       * Stream   0          0           0        0     N/A
+    IDEA_CBC     Block   16         16         128        8      8
+    RC2_CBC_40 * Block    5         16          40        8      8
+    RC4_40     * Stream   5         16          40        0     N/A
+    RC4_128      Stream  16         16         128        0     N/A
+    DES40_CBC  * Block    5          8          40        8      8
+    DES_CBC      Block    8          8          56        8      8
+    3DES_EDE_CBC Block   24         24         168        8      8
+
+   * Indicates IsExportable is true.
+
+   Type
+       Indicates whether this is a stream cipher or a block cipher
+       running in CBC mode.
+
+   Key Material
+       The number of bytes from the key_block that are used for
+       generating the write keys.
+
+   Expanded Key Material
+       The number of bytes actually fed into the encryption algorithm
+
+   Effective Key Bits
+       How much entropy material is in the key material being fed into
+       the encryption routines.
+
+   IV Size
+       How much data needs to be generated for the initialization
+       vector. Zero for stream ciphers; equal to the block size for
+       block ciphers.
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 62]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Block Size
+       The amount of data a block cipher enciphers in one chunk; a
+       block cipher running in CBC mode can only encrypt an even
+       multiple of its block size.
+
+      Hash      Hash      Padding
+    function    Size       Size
+      NULL       0          0
+      MD5        16         48
+      SHA        20         40
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 63]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+D. Implementation Notes
+
+   The TLS protocol cannot prevent many common security mistakes. This
+   section provides several recommendations to assist implementors.
+
+D.1. Temporary RSA keys
+
+   US Export restrictions limit RSA keys used for encryption to 512
+   bits, but do not place any limit on lengths of RSA keys used for
+   signing operations. Certificates often need to be larger than 512
+   bits, since 512-bit RSA keys are not secure enough for high-value
+   transactions or for applications requiring long-term security. Some
+   certificates are also designated signing-only, in which case they
+   cannot be used for key exchange.
+
+   When the public key in the certificate cannot be used for encryption,
+   the server signs a temporary RSA key, which is then exchanged. In
+   exportable applications, the temporary RSA key should be the maximum
+   allowable length (i.e., 512 bits). Because 512-bit RSA keys are
+   relatively insecure, they should be changed often. For typical
+   electronic commerce applications, it is suggested that keys be
+   changed daily or every 500 transactions, and more often if possible.
+   Note that while it is acceptable to use the same temporary key for
+   multiple transactions, it must be signed each time it is used.
+
+   RSA key generation is a time-consuming process. In many cases, a
+   low-priority process can be assigned the task of key generation.
+
+   Whenever a new key is completed, the existing temporary key can be
+   replaced with the new one.
+
+D.2. Random Number Generation and Seeding
+
+   TLS requires a cryptographically-secure pseudorandom number generator
+   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
+   based on secure hash operations, most notably MD5 and/or SHA, are
+   acceptable, but cannot provide more security than the size of the
+   random number generator state. (For example, MD5-based PRNGs usually
+   provide 128 bits of state.)
+
+   To estimate the amount of seed material being produced, add the
+   number of bits of unpredictable information in each seed byte. For
+   example, keystroke timing values taken from a PC compatible's 18.2 Hz
+   timer provide 1 or 2 secure bits each, even though the total size of
+   the counter value is 16 bits or more. To seed a 128-bit PRNG, one
+   would thus require approximately 100 such timer values.
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 64]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+ Warning: The seeding functions in RSAREF and versions of BSAFE prior to
+          3.0 are order-independent. For example, if 1000 seed bits are
+          supplied, one at a time, in 1000 separate calls to the seed
+          function, the PRNG will end up in a state which depends only
+          on the number of 0 or 1 seed bits in the seed data (i.e.,
+          there are 1001 possible final states). Applications using
+          BSAFE or RSAREF must take extra care to ensure proper seeding.
+          This may be accomplished by accumulating seed bits into a
+          buffer and processing them all at once or by processing an
+          incrementing counter with every seed bit; either method will
+          reintroduce order dependence into the seeding process.
+
+D.3. Certificates and authentication
+
+   Implementations are responsible for verifying the integrity of
+   certificates and should generally support certificate revocation
+   messages. Certificates should always be verified to ensure proper
+   signing by a trusted Certificate Authority (CA). The selection and
+   addition of trusted CAs should be done very carefully. Users should
+   be able to view information about the certificate and root CA.
+
+D.4. CipherSuites
+
+   TLS supports a range of key sizes and security levels, including some
+   which provide no or minimal security. A proper implementation will
+   probably not support many cipher suites. For example, 40-bit
+   encryption is easily broken, so implementations requiring strong
+   security should not allow 40-bit keys. Similarly, anonymous Diffie-
+   Hellman is strongly discouraged because it cannot prevent man-in-
+   the-middle attacks. Applications should also enforce minimum and
+   maximum key sizes. For example, certificate chains containing 512-bit
+   RSA keys or signatures are not appropriate for high-security
+   applications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 65]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+E. Backward Compatibility With SSL
+
+   For historical reasons and in order to avoid a profligate consumption
+   of reserved port numbers, application protocols which are secured by
+   TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
+   connection port: for example, the https protocol (HTTP secured by SSL
+   or TLS) uses port 443 regardless of which security protocol it is
+   using. Thus, some mechanism must be determined to distinguish and
+   negotiate among the various protocols.
+
+   TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both
+   is easy. TLS clients who wish to negotiate with SSL 3.0 servers
+   should send client hello messages using the SSL 3.0 record format and
+   client hello structure, sending {3, 1} for the version field to note
+   that they support TLS 1.0. If the server supports only SSL 3.0, it
+   will respond with an SSL 3.0 server hello; if it supports TLS, with a
+   TLS server hello. The negotiation then proceeds as appropriate for
+   the negotiated protocol.
+
+   Similarly, a TLS server which wishes to interoperate with SSL 3.0
+   clients should accept SSL 3.0 client hello messages and respond with
+   an SSL 3.0 server hello if an SSL 3.0 client hello is received which
+   has a version field of {3, 0}, denoting that this client does not
+   support TLS.
+
+   Whenever a client already knows the highest protocol known to a
+   server (for example, when resuming a session), it should initiate the
+   connection in that native protocol.
+
+   TLS 1.0 clients that support SSL Version 2.0 servers must send SSL
+   Version 2.0 client hello messages [SSL2]. TLS servers should accept
+   either client hello format if they wish to support SSL 2.0 clients on
+   the same connection port. The only deviations from the Version 2.0
+   specification are the ability to specify a version with a value of
+   three and the support for more ciphering types in the CipherSpec.
+
+ Warning: The ability to send Version 2.0 client hello messages will be
+          phased out with all due haste. Implementors should make every
+          effort to move forward as quickly as possible. Version 3.0
+          provides better mechanisms for moving to newer versions.
+
+   The following cipher specifications are carryovers from SSL Version
+   2.0. These are assumed to use RSA for key exchange and
+   authentication.
+
+       V2CipherSpec TLS_RC4_128_WITH_MD5          = { 0x01,0x00,0x80 };
+       V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
+       V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5  = { 0x03,0x00,0x80 };
+
+
+
+Dierks & Allen              Standards Track                    [Page 66]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
+                                                  = { 0x04,0x00,0x80 };
+       V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5     = { 0x05,0x00,0x80 };
+       V2CipherSpec TLS_DES_64_CBC_WITH_MD5       = { 0x06,0x00,0x40 };
+       V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
+
+   Cipher specifications native to TLS can be included in Version 2.0
+   client hello messages using the syntax below. Any V2CipherSpec
+   element with its first byte equal to zero will be ignored by Version
+   2.0 servers. Clients sending any of the above V2CipherSpecs should
+   also include the TLS equivalent (see Appendix A.5):
+
+       V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
+
+E.1. Version 2 client hello
+
+   The Version 2.0 client hello message is presented below using this
+   document's presentation model. The true definition is still assumed
+   to be the SSL Version 2.0 specification.
+
+       uint8 V2CipherSpec[3];
+
+       struct {
+           uint8 msg_type;
+           Version version;
+           uint16 cipher_spec_length;
+           uint16 session_id_length;
+           uint16 challenge_length;
+           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
+           opaque session_id[V2ClientHello.session_id_length];
+           Random challenge;
+       } V2ClientHello;
+
+   msg_type
+       This field, in conjunction with the version field, identifies a
+       version 2 client hello message. The value should be one (1).
+
+   version
+       The highest version of the protocol supported by the client
+       (equals ProtocolVersion.version, see Appendix A.1).
+
+   cipher_spec_length
+       This field is the total length of the field cipher_specs. It
+       cannot be zero and must be a multiple of the V2CipherSpec length
+       (3).
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 67]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   session_id_length
+       This field must have a value of either zero or 16. If zero, the
+       client is creating a new session. If 16, the session_id field
+       will contain the 16 bytes of session identification.
+
+   challenge_length
+       The length in bytes of the client's challenge to the server to
+       authenticate itself. This value must be 32.
+
+   cipher_specs
+       This is a list of all CipherSpecs the client is willing and able
+       to use. There must be at least one CipherSpec acceptable to the
+       server.
+
+   session_id
+       If this field's length is not zero, it will contain the
+       identification for a session that the client wishes to resume.
+
+   challenge
+       The client challenge to the server for the server to identify
+       itself is a (nearly) arbitrary length random. The TLS server will
+       right justify the challenge data to become the ClientHello.random
+       data (padded with leading zeroes, if necessary), as specified in
+       this protocol specification. If the length of the challenge is
+       greater than 32 bytes, only the last 32 bytes are used. It is
+       legitimate (but not necessary) for a V3 server to reject a V2
+       ClientHello that has fewer than 16 bytes of challenge data.
+
+ Note: Requests to resume a TLS session should use a TLS client hello.
+
+E.2. Avoiding man-in-the-middle version rollback
+
+   When TLS clients fall back to Version 2.0 compatibility mode, they
+   should use special PKCS #1 block formatting. This is done so that TLS
+   servers will reject Version 2.0 sessions with TLS-capable clients.
+
+   When TLS clients are in Version 2.0 compatibility mode, they set the
+   right-hand (least-significant) 8 random bytes of the PKCS padding
+   (not including the terminal null of the padding) for the RSA
+   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
+   to 0x03 (the other padding bytes are random). After decrypting the
+   ENCRYPTED-KEY-DATA field, servers that support TLS should issue an
+   error if these eight padding bytes are 0x03. Version 2.0 servers
+   receiving blocks padded in this manner will proceed normally.
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 68]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+F. Security analysis
+
+   The TLS protocol is designed to establish a secure connection between
+   a client and a server communicating over an insecure channel. This
+   document makes several traditional assumptions, including that
+   attackers have substantial computational resources and cannot obtain
+   secret information from sources outside the protocol. Attackers are
+   assumed to have the ability to capture, modify, delete, replay, and
+   otherwise tamper with messages sent over the communication channel.
+   This appendix outlines how TLS has been designed to resist a variety
+   of attacks.
+
+F.1. Handshake protocol
+
+   The handshake protocol is responsible for selecting a CipherSpec and
+   generating a Master Secret, which together comprise the primary
+   cryptographic parameters associated with a secure session. The
+   handshake protocol can also optionally authenticate parties who have
+   certificates signed by a trusted certificate authority.
+
+F.1.1. Authentication and key exchange
+
+   TLS supports three authentication modes: authentication of both
+   parties, server authentication with an unauthenticated client, and
+   total anonymity. Whenever the server is authenticated, the channel is
+   secure against man-in-the-middle attacks, but completely anonymous
+   sessions are inherently vulnerable to such attacks.  Anonymous
+   servers cannot authenticate clients. If the server is authenticated,
+   its certificate message must provide a valid certificate chain
+   leading to an acceptable certificate authority.  Similarly,
+   authenticated clients must supply an acceptable certificate to the
+   server. Each party is responsible for verifying that the other's
+   certificate is valid and has not expired or been revoked.
+
+   The general goal of the key exchange process is to create a
+   pre_master_secret known to the communicating parties and not to
+   attackers. The pre_master_secret will be used to generate the
+   master_secret (see Section 8.1). The master_secret is required to
+   generate the certificate verify and finished messages, encryption
+   keys, and MAC secrets (see Sections 7.4.8, 7.4.9 and 6.3). By sending
+   a correct finished message, parties thus prove that they know the
+   correct pre_master_secret.
+
+F.1.1.1. Anonymous key exchange
+
+   Completely anonymous sessions can be established using RSA or
+   Diffie-Hellman for key exchange. With anonymous RSA, the client
+   encrypts a pre_master_secret with the server's uncertified public key
+
+
+
+Dierks & Allen              Standards Track                    [Page 69]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   extracted from the server key exchange message. The result is sent in
+   a client key exchange message. Since eavesdroppers do not know the
+   server's private key, it will be infeasible for them to decode the
+   pre_master_secret. (Note that no anonymous RSA Cipher Suites are
+   defined in this document).
+
+   With Diffie-Hellman, the server's public parameters are contained in
+   the server key exchange message and the client's are sent in the
+   client key exchange message. Eavesdroppers who do not know the
+   private values should not be able to find the Diffie-Hellman result
+   (i.e. the pre_master_secret).
+
+ Warning: Completely anonymous connections only provide protection
+          against passive eavesdropping. Unless an independent tamper-
+          proof channel is used to verify that the finished messages
+          were not replaced by an attacker, server authentication is
+          required in environments where active man-in-the-middle
+          attacks are a concern.
+
+F.1.1.2. RSA key exchange and authentication
+
+   With RSA, key exchange and server authentication are combined. The
+   public key may be either contained in the server's certificate or may
+   be a temporary RSA key sent in a server key exchange message.  When
+   temporary RSA keys are used, they are signed by the server's RSA or
+   DSS certificate. The signature includes the current
+   ClientHello.random, so old signatures and temporary keys cannot be
+   replayed. Servers may use a single temporary RSA key for multiple
+   negotiation sessions.
+
+ Note: The temporary RSA key option is useful if servers need large
+       certificates but must comply with government-imposed size limits
+       on keys used for key exchange.
+
+   After verifying the server's certificate, the client encrypts a
+   pre_master_secret with the server's public key. By successfully
+   decoding the pre_master_secret and producing a correct finished
+   message, the server demonstrates that it knows the private key
+   corresponding to the server certificate.
+
+   When RSA is used for key exchange, clients are authenticated using
+   the certificate verify message (see Section 7.4.8). The client signs
+   a value derived from the master_secret and all preceding handshake
+   messages. These handshake messages include the server certificate,
+   which binds the signature to the server, and ServerHello.random,
+   which binds the signature to the current handshake process.
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 70]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+F.1.1.3. Diffie-Hellman key exchange with authentication
+
+   When Diffie-Hellman key exchange is used, the server can either
+   supply a certificate containing fixed Diffie-Hellman parameters or
+   can use the server key exchange message to send a set of temporary
+   Diffie-Hellman parameters signed with a DSS or RSA certificate.
+   Temporary parameters are hashed with the hello.random values before
+   signing to ensure that attackers do not replay old parameters. In
+   either case, the client can verify the certificate or signature to
+   ensure that the parameters belong to the server.
+
+   If the client has a certificate containing fixed Diffie-Hellman
+   parameters, its certificate contains the information required to
+   complete the key exchange. Note that in this case the client and
+   server will generate the same Diffie-Hellman result (i.e.,
+   pre_master_secret) every time they communicate. To prevent the
+   pre_master_secret from staying in memory any longer than necessary,
+   it should be converted into the master_secret as soon as possible.
+   Client Diffie-Hellman parameters must be compatible with those
+   supplied by the server for the key exchange to work.
+
+   If the client has a standard DSS or RSA certificate or is
+   unauthenticated, it sends a set of temporary parameters to the server
+   in the client key exchange message, then optionally uses a
+   certificate verify message to authenticate itself.
+
+F.1.2. Version rollback attacks
+
+   Because TLS includes substantial improvements over SSL Version 2.0,
+   attackers may try to make TLS-capable clients and servers fall back
+   to Version 2.0. This attack can occur if (and only if) two TLS-
+   capable parties use an SSL 2.0 handshake.
+
+   Although the solution using non-random PKCS #1 block type 2 message
+   padding is inelegant, it provides a reasonably secure way for Version
+   3.0 servers to detect the attack. This solution is not secure against
+   attackers who can brute force the key and substitute a new
+   ENCRYPTED-KEY-DATA message containing the same key (but with normal
+   padding) before the application specified wait threshold has expired.
+   Parties concerned about attacks of this scale should not be using
+   40-bit encryption keys anyway. Altering the padding of the least-
+   significant 8 bytes of the PKCS padding does not impact security for
+   the size of the signed hashes and RSA key lengths used in the
+   protocol, since this is essentially equivalent to increasing the
+   input block size by 8 bytes.
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 71]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+F.1.3. Detecting attacks against the handshake protocol
+
+   An attacker might try to influence the handshake exchange to make the
+   parties select different encryption algorithms than they would
+   normally choose. Because many implementations will support 40-bit
+   exportable encryption and some may even support null encryption or
+   MAC algorithms, this attack is of particular concern.
+
+   For this attack, an attacker must actively change one or more
+   handshake messages. If this occurs, the client and server will
+   compute different values for the handshake message hashes. As a
+   result, the parties will not accept each others' finished messages.
+   Without the master_secret, the attacker cannot repair the finished
+   messages, so the attack will be discovered.
+
+F.1.4. Resuming sessions
+
+   When a connection is established by resuming a session, new
+   ClientHello.random and ServerHello.random values are hashed with the
+   session's master_secret. Provided that the master_secret has not been
+   compromised and that the secure hash operations used to produce the
+   encryption keys and MAC secrets are secure, the connection should be
+   secure and effectively independent from previous connections.
+   Attackers cannot use known encryption keys or MAC secrets to
+   compromise the master_secret without breaking the secure hash
+   operations (which use both SHA and MD5).
+
+   Sessions cannot be resumed unless both the client and server agree.
+   If either party suspects that the session may have been compromised,
+   or that certificates may have expired or been revoked, it should
+   force a full handshake. An upper limit of 24 hours is suggested for
+   session ID lifetimes, since an attacker who obtains a master_secret
+   may be able to impersonate the compromised party until the
+   corresponding session ID is retired. Applications that may be run in
+   relatively insecure environments should not write session IDs to
+   stable storage.
+
+F.1.5. MD5 and SHA
+
+   TLS uses hash functions very conservatively. Where possible, both MD5
+   and SHA are used in tandem to ensure that non-catastrophic flaws in
+   one algorithm will not break the overall protocol.
+
+F.2. Protecting application data
+
+   The master_secret is hashed with the ClientHello.random and
+   ServerHello.random to produce unique data encryption keys and MAC
+   secrets for each connection.
+
+
+
+Dierks & Allen              Standards Track                    [Page 72]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Outgoing data is protected with a MAC before transmission. To prevent
+   message replay or modification attacks, the MAC is computed from the
+   MAC secret, the sequence number, the message length, the message
+   contents, and two fixed character strings. The message type field is
+   necessary to ensure that messages intended for one TLS Record Layer
+   client are not redirected to another. The sequence number ensures
+   that attempts to delete or reorder messages will be detected. Since
+   sequence numbers are 64-bits long, they should never overflow.
+   Messages from one party cannot be inserted into the other's output,
+   since they use independent MAC secrets. Similarly, the server-write
+   and client-write keys are independent so stream cipher keys are used
+   only once.
+
+   If an attacker does break an encryption key, all messages encrypted
+   with it can be read. Similarly, compromise of a MAC key can make
+   message modification attacks possible. Because MACs are also
+   encrypted, message-alteration attacks generally require breaking the
+   encryption algorithm as well as the MAC.
+
+ Note: MAC secrets may be larger than encryption keys, so messages can
+       remain tamper resistant even if encryption keys are broken.
+
+F.3. Final notes
+
+   For TLS to be able to provide a secure connection, both the client
+   and server systems, keys, and applications must be secure. In
+   addition, the implementation must be free of security errors.
+
+   The system is only as strong as the weakest key exchange and
+   authentication algorithm supported, and only trustworthy
+   cryptographic functions should be used. Short public keys, 40-bit
+   bulk encryption keys, and anonymous servers should be used with great
+   caution. Implementations and users must be careful when deciding
+   which certificates and certificate authorities are acceptable; a
+   dishonest certificate authority can do tremendous damage.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 73]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+G. Patent Statement
+
+   Some of the cryptographic algorithms proposed for use in this
+   protocol have patent claims on them. In addition Netscape
+   Communications Corporation has a patent claim on the Secure Sockets
+   Layer (SSL) work that this standard is based on. The Internet
+   Standards Process as defined in RFC 2026 requests that a statement be
+   obtained from a Patent holder indicating that a license will be made
+   available to applicants under reasonable terms and conditions.
+
+   The Massachusetts Institute of Technology has granted RSA Data
+   Security, Inc., exclusive sub-licensing rights to the following
+   patent issued in the United States:
+
+       Cryptographic Communications System and Method ("RSA"), No.
+       4,405,829
+
+   Netscape Communications Corporation has been issued the following
+   patent in the United States:
+
+       Secure Socket Layer Application Program Apparatus And Method
+       ("SSL"), No. 5,657,390
+
+   Netscape Communications has issued the following statement:
+
+       Intellectual Property Rights
+
+       Secure Sockets Layer
+
+       The United States Patent and Trademark Office ("the PTO")
+       recently issued U.S. Patent No. 5,657,390 ("the SSL Patent")  to
+       Netscape for inventions described as Secure Sockets Layers
+       ("SSL"). The IETF is currently considering adopting SSL as a
+       transport protocol with security features.  Netscape encourages
+       the royalty-free adoption and use of the SSL protocol upon the
+       following terms and conditions:
+
+         * If you already have a valid SSL Ref license today which
+           includes source code from Netscape, an additional patent
+           license under the SSL patent is not required.
+
+         * If you don't have an SSL Ref license, you may have a royalty
+           free license to build implementations covered by the SSL
+           Patent Claims or the IETF TLS specification provided that you
+           do not to assert any patent rights against Netscape or other
+           companies for the implementation of SSL or the IETF TLS
+           recommendation.
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 74]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+       What are "Patent Claims":
+
+       Patent claims are claims in an issued foreign or domestic patent
+       that:
+
+        1) must be infringed in order to implement methods or build
+           products according to the IETF TLS specification;  or
+
+        2) patent claims which require the elements of the SSL patent
+           claims and/or their equivalents to be infringed.
+
+   The Internet Society, Internet Architecture Board, Internet
+   Engineering Steering Group and the Corporation for National Research
+   Initiatives take no position on the validity or scope of the patents
+   and patent applications, nor on the appropriateness of the terms of
+   the assurance. The Internet Society and other groups mentioned above
+   have not made any determination as to any other intellectual property
+   rights which may apply to the practice of this standard.  Any further
+   consideration of these matters is the user's own responsibility.
+
+Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+References
+
+   [3DES]   W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
+            IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
+
+   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
+            Protocols Based on RSA Encryption Standard PKCS #1" in
+            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
+            1--12, 1998.
+
+   [DES]    ANSI X3.106, "American National Standard for Information
+            Systems-Data Link Encryption," American National Standards
+            Institute, 1983.
+
+   [DH1]    W. Diffie and M. E. Hellman, "New Directions in
+            Cryptography," IEEE Transactions on Information Theory, V.
+            IT-22, n. 6, Jun 1977, pp. 74-84.
+
+   [DSS]    NIST FIPS PUB 186, "Digital Signature Standard," National
+            Institute of Standards and Technology, U.S. Department of
+            Commerce, May 18, 1994.
+
+   [FTP]    Postel J., and J. Reynolds, "File Transfer Protocol", STD 9,
+            RFC 959, October 1985.
+
+
+
+Dierks & Allen              Standards Track                    [Page 75]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   [HTTP]   Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
+            Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
+
+   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:  Keyed-
+            Hashing for Message Authentication," RFC 2104, February
+            1997.
+
+   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH
+            Series in Information Processing, v. 1, Konstanz: Hartung-
+            Gorre Verlag, 1992.
+
+   [MD2]    Kaliski, B., "The MD2 Message Digest Algorithm", RFC 1319,
+            April 1992.
+
+   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
+            April 1992.
+
+   [PKCS1]  RSA Laboratories, "PKCS #1: RSA Encryption Standard,"
+            version 1.5, November 1993.
+
+   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
+            Standard," version 1.5, November 1993.
+
+   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
+            Standard," version 1.5, November 1993.
+
+   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
+            Public Key Infrastructure: Part I: X.509 Certificate and CRL
+            Profile", RFC 2459, January 1999.
+
+   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption
+            Algorithm", RFC 2268, January 1998.
+
+   [RC4]    Thayer, R. and K. Kaukonen, A Stream Cipher Encryption
+            Algorithm, Work in Progress.
+
+   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
+            Obtaining Digital Signatures and Public-Key Cryptosystems,"
+            Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-
+            126.
+
+   [RSADSI] Contact RSA Data Security, Inc., Tel: [phone]
+
+   [SCH]    B. Schneier. Applied Cryptography: Protocols, Algorithms,
+            and Source Code in C, Published by John Wiley & Sons, Inc.
+            1994.
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 76]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   [SHA]    NIST FIPS PUB 180-1, "Secure Hash Standard," National
+            Institute of Standards and Technology, U.S. Department of
+            Commerce, Work in Progress, May 31, 1994.
+
+   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
+            Corp., Feb 9, 1995.
+
+   [SSL3]   A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
+            Netscape Communications Corp., Nov 18, 1996.
+
+   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
+            September 1981.
+
+   [TEL]    Postel J., and J. Reynolds, "Telnet Protocol
+            Specifications", STD 8, RFC 854, May 1993.
+
+   [TEL]    Postel J., and J. Reynolds, "Telnet Option Specifications",
+            STD 8, RFC 855, May 1993.
+
+   [X509]   CCITT. Recommendation X.509: "The Directory - Authentication
+            Framework". 1988.
+
+   [XDR]    R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External
+            Data Representation Standard, August 1995.
+
+Credits
+
+   Win Treese
+   Open Market
+
+   EMail: [e-mail]
+
+
+   Editors
+
+   Christopher Allen                  Tim Dierks
+   Certicom                           Certicom
+
+   EMail: [e-mail]         EMail: [e-mail]
+
+
+   Authors' Addresses
+
+   Tim Dierks                         Philip L. Karlton
+   Certicom                           Netscape Communications
+
+   EMail: [e-mail]
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 77]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Alan O. Freier                     Paul C. Kocher
+   Netscape Communications            Independent Consultant
+
+   EMail: [e-mail]         EMail: [e-mail]
+
+
+   Other contributors
+
+   Martin Abadi                       Robert Relyea
+   Digital Equipment Corporation      Netscape Communications
+
+   EMail: [e-mail]               EMail: [e-mail]
+
+   Ran Canetti                        Jim Roskind
+   IBM Watson Research Center         Netscape Communications
+
+   EMail: [e-mail]      EMail: [e-mail]
+
+
+   Taher Elgamal                      Micheal J. Sabin, Ph. D.
+   Securify                           Consulting Engineer
+
+   EMail: [e-mail]        EMail: [e-mail]
+
+
+   Anil R. Gangolli                   Dan Simon
+   Structured Arts Computing Corp.    Microsoft
+
+   EMail: [e-mail] EMail:  [e-mail]
+
+
+   Kipp E.B. Hickman                  Tom Weinstein
+   Netscape Communications            Netscape Communications
+
+   EMail: [e-mail]           EMail: [e-mail]
+
+
+   Hugo Krawczyk
+   IBM Watson Research Center
+
+   EMail: [e-mail]
+
+Comments
+
+   The discussion list for the IETF TLS working group is located at the
+   e-mail address <[e-mail]>. Information on the
+   group and information on how to subscribe to the list is at
+   <http://lists.consensus.com/>.
+
+
+
+Dierks & Allen              Standards Track                    [Page 78]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+   Archives of the list can be found at:
+       <http://www.imc.org/ietf-tls/mail-archive/>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 79]
+
+RFC 2246              The TLS Protocol Version 1.0          January 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dierks & Allen              Standards Track                    [Page 80]
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/rfcs/rfc2428.txt	Tue Jul 13 01:35:15 2004 +0000
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                          M. Allman
+Request for Comments: 2428                  NASA Lewis/Sterling Software
+Category: Standards Track                                   S. Ostermann
+                                                         Ohio University
+                                                                 C. Metz
+                                                           The Inner Net
+                                                          September 1998
+
+
+                    FTP Extensions for IPv6 and NATs
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   The specification for the File Transfer Protocol assumes that the
+   underlying network protocol uses a 32-bit network address
+   (specifically IP version 4).  With the deployment of version 6 of the
+   Internet Protocol, network addresses will no longer be 32-bits.  This
+   paper specifies extensions to FTP that will allow the protocol to
+   work over IPv4 and IPv6.  In addition, the framework defined can
+   support additional network protocols in the future.
+
+1.  Introduction
+
+   The keywords, such as MUST and SHOULD, found in this document are
+   used as defined in RFC 2119 [Bra97].
+
+   The File Transfer Protocol [PR85] only provides the ability to
+   communicate information about IPv4 data connections.  FTP assumes
+   network addresses will be 32 bits in length.  However, with the
+   deployment of version 6 of the Internet Protocol [DH96] addresses
+   will no longer be 32 bits long.  RFC 1639 [Pis94] specifies
+   extensions to FTP to enable its use over various network protocols.
+   Unfortunately, the mechanism can fail in a multi-protocol
+   environment.  During the transition between IPv4 and IPv6, FTP needs
+   the ability to negotiate the network protocol that will be used for
+   data transfer.
+
+
+
+Allman, et. al.             Standards Track                     [Page 1]
+
+RFC 2428            FTP Extensions for IPv6 and NATs      September 1998
+
+
+   This document provides a specification for a way that FTP can
+   communicate data connection endpoint information for network
+   protocols other than IPv4.  In this specification, the FTP commands
+   PORT and PASV are replaced with EPRT and EPSV, respectively.  This
+   document is organized as follows.  Section 2 outlines the EPRT
+   command and Section 3 outlines the EPSV command.  Section 4 defines
+   the utilization of these two new FTP commands.  Section 5 briefly
+   presents security considerations.  Finally, Section 6 provides
+   conclusions.
+
+2.  The EPRT Command
+
+   The EPRT command allows for the specification of an extended address
+   for the data connection.  The extended address MUST consist of the
+   network protocol as well as the network and transport addresses.  The
+   format of EPRT is:
+
+           EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>
+
+   The EPRT command keyword MUST be followed by a single space (ASCII
+   32).  Following the space, a delimiter character (<d>) MUST be
+   specified.  The delimiter character MUST be one of the ASCII
+   characters in range 33-126 inclusive.  The character "|" (ASCII 124)
+   is recommended unless it coincides with a character needed to encode
+   the network address.
+
+   The <net-prt> argument MUST be an address family number defined by
+   IANA in the latest Assigned Numbers RFC (RFC 1700 [RP94] as of the
+   writing of this document).  This number indicates the protocol to be
+   used (and, implicitly, the address length).  This document will use
+   two of address family numbers from [RP94] as examples, according to
+   the following table:
+
+        AF Number   Protocol
+        ---------   --------
+        1           Internet Protocol, Version 4 [Pos81a]
+        2           Internet Protocol, Version 6 [DH96]
+
+   The <net-addr> is a protocol specific string representation of the
+   network address.  For the two address families specified above (AF
+   Number 1 and 2), addresses MUST be in the following format:
+
+        AF Number   Address Format      Example
+        ---------   --------------      -------
+        1           dotted decimal      132.235.1.2
+        2           IPv6 string         1080::8:800:200C:417A
+                    representations
+                    defined in [HD96]
+
+
+
+Allman, et. al.             Standards Track                     [Page 2]
+
+RFC 2428            FTP Extensions for IPv6 and NATs      September 1998
+
+
+   The <tcp-port> argument must be the string representation of the
+   number of the TCP port on which the host is listening for the data
+   connection.
+
+   The following are sample EPRT commands:
+
+        EPRT |1|132.235.1.2|6275|
+
+        EPRT |2|1080::8:800:200C:417A|5282|
+
+   The first command specifies that the server should use IPv4 to open a
+   data connection to the host "132.235.1.2" on TCP port 6275.  The
+   second command specifies that the server should use the IPv6 network
+   protocol and the network address "1080::8:800:200C:417A" to open a
+   TCP data connection on port 5282.
+
+   Upon receipt of a valid EPRT command, the server MUST return a code
+   of 200 (Command OK).  The standard negative error code 500 and 501
+   [PR85] are sufficient to handle most errors (e.g., syntax errors)
+   involving the EPRT command.  However, an additional error code is
+   needed.  The response code 522 indicates that the server does not
+   support the requested network protocol.  The interpretation of this
+   new error code is:
+
+        5yz Negative Completion
+        x2z Connections
+        xy2 Extended Port Failure - unknown network protocol
+
+   The text portion of the response MUST indicate which network
+   protocols the server does support.  If the network protocol is
+   unsupported, the format of the response string MUST be:
+
+        <text stating that the network protocol is unsupported> \
+            (prot1,prot2,...,protn)
+
+   Both the numeric code specified above and the protocol information
+   between the characters '(' and ')' are intended for the software
+   automata receiving the response; the textual message between the
+   numeric code and the '(' is intended for the human user and can be
+   any arbitrary text, but MUST NOT include the characters '(' and ')'.
+   In the above case, the text SHOULD indicate that the network protocol
+   in the EPRT command is not supported by the server.  The list of
+   protocols inside the parenthesis MUST be a comma separated list of
+   address family numbers.  Two example response strings follow:
+
+        Network protocol not supported, use (1)
+
+        Network protocol not supported, use (1,2)
+
+
+
+Allman, et. al.             Standards Track                     [Page 3]
+
+RFC 2428            FTP Extensions for IPv6 and NATs      September 1998
+
+
+3.  The EPSV Command
+
+   The EPSV command requests that a server listen on a data port and
+   wait for a connection.  The EPSV command takes an optional argument.
+   The response to this command includes only the TCP port number of the
+   listening connection.  The format of the response, however, is
+   similar to the argument of the EPRT command.  This allows the same
+   parsing routines to be used for both commands.  In addition, the
+   format leaves a place holder for the network protocol and/or network
+   address, which may be needed in the EPSV response in the future.  The
+   response code for entering passive mode using an extended address
+   MUST be 229.  The interpretation of this code, according to [PR85]
+   is:
+
+        2yz Positive Completion
+        x2z Connections
+        xy9 Extended Passive Mode Entered
+
+   The text returned in response to the EPSV command MUST be:
+
+        <text indicating server is entering extended passive mode> \
+            (<d><d><d><tcp-port><d>)
+
+   The portion of the string enclosed in parentheses MUST be the exact
+   string needed by the EPRT command to open the data connection, as
+   specified above.
+
+   The first two fields contained in the parenthesis MUST be blank.  The
+   third field MUST be the string representation of the TCP port number
+   on which the server is listening for a data connection.  The network
+   protocol used by the data connection will be the same network
+   protocol used by the control connection.  In addition, the network
+   address used to establish the data connection will be the same
+   network address used for the control connection.  An example response
+   string follows:
+
+        Entering Extended Passive Mode (|||6446|)
+
+   The standard negative error codes 500 and 501 are sufficient to
+   handle all errors involving the EPSV command (e.g., syntax errors).
+
+   When the EPSV command is issued with no argument, the server will
+   choose the network protocol for the data connection based on the
+   protocol used for the control connection.  However, in the case of
+   proxy FTP, this protocol might not be appropriate for communication
+   between the two servers.  Therefore, the client needs to be able to
+   request a specific protocol.  If the server returns a protocol that
+   is not supported by the host that will be connecting to the port, the
+
+
+
+Allman, et. al.             Standards Track                     [Page 4]
+
+RFC 2428            FTP Extensions for IPv6 and NATs      September 1998
+
+
+   client MUST issue an ABOR (abort) command to allow the server to
+   close down the listening connection.  The client can then send an
+   EPSV command requesting the use of a specific network protocol, as
+   follows:
+
+        EPSV<space><net-prt>
+
+   If the requested protocol is supported by the server, it SHOULD use
+   the protocol.  If not, the server MUST return the 522 error messages
+   as outlined in section 2.
+
+   Finally, the EPSV command can be used with the argument "ALL" to
+   inform Network Address Translators that the EPRT command (as well as
+   other data commands) will no longer be used.  An example of this
+   command follows:
+
+        EPSV<space>ALL
+
+   Upon receipt of an EPSV ALL command, the server MUST reject all data
+   connection setup commands other than EPSV (i.e., EPRT, PORT, PASV, et
+   al.).  This use of the EPSV command is further explained in section
+   4.
+
+4.  Command Usage
+
+   For all FTP transfers where the control and data connection(s) are
+   being established between the same two machines, the EPSV command
+   MUST be used.  Using the EPSV command benefits performance of
+   transfers that traverse firewalls or Network Address Translators
+   (NATs).  RFC 1579 [Bel94] recommends using the passive command when
+   behind firewalls since firewalls do not generally allow incoming
+   connections (which are required when using the PORT (EPRT) command).
+   In addition, using EPSV as defined in this document does not require
+   NATs to change the network address in the traffic as it is forwarded.
+   The NAT would have to change the address if the EPRT command was
+   used.  Finally, if the client issues an "EPSV ALL" command, NATs may
+   be able to put the connection on a "fast path" through the
+   translator, as the EPRT command will never be used and therefore,
+   translation of the data portion of the segments will never be needed.
+   When a client only expects to do two-way FTP transfers, it SHOULD
+   issue this command as soon as possible.  If a client later finds that
+   it must do a three-way FTP transfer after issuing an EPSV ALL
+   command, a new FTP session MUST be started.
+
+
+
+
+
+
+
+
+Allman, et. al.             Standards Track                     [Page 5]
+
+RFC 2428            FTP Extensions for IPv6 and NATs      September 1998
+
+
+5.  Security Issues
+
+   The authors do not believe that these changes to FTP introduce new
+   security problems.  A companion Work in Progress [AO98] is a more
+   general discussion of FTP security issues and techniques to reduce
+   these security problems.
+
+6.  Conclusions
+
+   The extensions specified in this paper will enable FTP to operate
+   over a variety of network protocols.
+
+References
+
+   [AO98]   Allman, M., and S. Ostermann, "FTP Security
+            Considerations", Work in Progress.
+
+   [Bel94]  Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February
+            1994.
+
+   [Bra97]  Bradner, S., "Key words for use in RFCs to Indicate
+            Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [DH96]   Deering, S., and R. Hinden, "Internet Protocol, Version 6
+            (IPv6) Specification", RFC 1883, December 1995.
+
+   [HD96]   Hinden, R., and S. Deering, "IP Version 6 Addressing
+            Architecture", RFC 2373, July 1998.
+
+   [Pis94]  Piscitello, D., "FTP Operation Over Big Address Records
+            (FOOBAR)", RFC 1639, June 1994.
+
+   [Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September
+            1981.
+
+   [Pos81b] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
+            September 1981.
+
+   [PR85]   Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
+            STD 9, RFC 959, October 1985.
+
+   [RP94]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
+            1700, October 1994.  See also:
+            http://www.iana.org/numbers.html
+
+
+
+
+
+
+
+Allman, et. al.             Standards Track                     [Page 6]
+
+RFC 2428            FTP Extensions for IPv6 and NATs      September 1998
+
+
+Authors' Addresses
+
+   Mark Allman
+   NASA Lewis Research Center/Sterling Software
+   21000 Brookpark Rd.  MS 54-2
+   Cleveland, OH  44135
+
+   Phone: [phone]
+   EMail: [e-mail]
+   http://gigahertz.lerc.nasa.gov/~mallman/
+
+
+   Shawn Ostermann
+   School of Electrical Engineering and Computer Science
+   Ohio University
+   416 Morton Hall
+   Athens, OH  45701
+
+   Phone: [phone]
+   EMail: [e-mail]
+
+
+   Craig Metz
+   The Inner Net
+   Box 10314-1954
+   Blacksburg, VA  24062-0314
+
+   Phone:  (DSN) 754-8590
+   EMail: [e-mail]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman, et. al.             Standards Track                     [Page 7]
+
+RFC 2428            FTP Extensions for IPv6 and NATs      September 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman, et. al.             Standards Track                     [Page 8]
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/rfcs/rfc959.txt	Tue Jul 13 01:35:15 2004 +0000
@@ -0,0 +1,3933 @@
+
+                                                                        
+Network Working Group                                          J. Postel
+Request for Comments: 959                                    J. Reynolds
+                                                                     ISI
+Obsoletes RFC: 765 (IEN 149)                                October 1985
+
+                      FILE TRANSFER PROTOCOL (FTP)
+
+
+Status of this Memo
+
+   This memo is the official specification of the File Transfer
+   Protocol (FTP).  Distribution of this memo is unlimited.
+
+   The following new optional commands are included in this edition of
+   the specification:
+
+      CDUP (Change to Parent Directory), SMNT (Structure Mount), STOU
+      (Store Unique), RMD (Remove Directory), MKD (Make Directory), PWD
+      (Print Directory), and SYST (System).
+
+   Note that this specification is compatible with the previous edition.
+
+1.  INTRODUCTION
+
+   The objectives of FTP are 1) to promote sharing of files (computer
+   programs and/or data), 2) to encourage indirect or implicit (via
+   programs) use of remote computers, 3) to shield a user from
+   variations in file storage systems among hosts, and 4) to transfer
+   data reliably and efficiently.  FTP, though usable directly by a user
+   at a terminal, is designed mainly for use by programs.
+
+   The attempt in this specification is to satisfy the diverse needs of
+   users of maxi-hosts, mini-hosts, personal workstations, and TACs,
+   with a simple, and easily implemented protocol design.
+
+   This paper assumes knowledge of the Transmission Control Protocol
+   (TCP) [2] and the Telnet Protocol [3].  These documents are contained
+   in the ARPA-Internet protocol handbook [1].
+
+2.  OVERVIEW
+
+   In this section, the history, the terminology, and the FTP model are
+   discussed.  The terms defined in this section are only those that
+   have special significance in FTP.  Some of the terminology is very
+   specific to the FTP model; some readers may wish to turn to the
+   section on the FTP model while reviewing the terminology.
+
+
+
+
+
+
+
+Postel & Reynolds                                               [Page 1]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   2.1.  HISTORY
+
+      FTP has had a long evolution over the years.  Appendix III is a
+      chronological compilation of Request for Comments documents
+      relating to FTP.  These include the first proposed file transfer
+      mechanisms in 1971 that were developed for implementation on hosts
+      at M.I.T. (RFC 114), plus comments and discussion in RFC 141.
+
+      RFC 172 provided a user-level oriented protocol for file transfer
+      between host computers (including terminal IMPs).  A revision of
+      this as RFC 265, restated FTP for additional review, while RFC 281
+      suggested further changes.  The use of a "Set Data Type"
+      transaction was proposed in RFC 294 in January 1982.
+
+      RFC 354 obsoleted RFCs 264 and 265.  The File Transfer Protocol
+      was now defined as a protocol for file transfer between HOSTs on
+      the ARPANET, with the primary function of FTP defined as
+      transfering files efficiently and reliably among hosts and
+      allowing the convenient use of remote file storage capabilities.
+      RFC 385 further commented on errors, emphasis points, and
+      additions to the protocol, while RFC 414 provided a status report
+      on the working server and user FTPs.  RFC 430, issued in 1973,
+      (among other RFCs too numerous to mention) presented further
+      comments on FTP.  Finally, an "official" FTP document was
+      published as RFC 454.
+
+      By July 1973, considerable changes from the last versions of FTP
+      were made, but the general structure remained the same.  RFC 542
+      was published as a new "official" specification to reflect these
+      changes.  However, many implementations based on the older
+      specification were not updated.
+
+      In 1974, RFCs 607 and 614 continued comments on FTP.  RFC 624
+      proposed further design changes and minor modifications.  In 1975,
+      RFC 686 entitled, "Leaving Well Enough Alone", discussed the
+      differences between all of the early and later versions of FTP.
+      RFC 691 presented a minor revision of RFC 686, regarding the
+      subject of print files.
+
+      Motivated by the transition from the NCP to the TCP as the
+      underlying protocol, a phoenix was born out of all of the above
+      efforts in RFC 765 as the specification of FTP for use on TCP.
+
+      This current edition of the FTP specification is intended to
+      correct some minor documentation errors, to improve the
+      explanation of some protocol features, and to add some new
+      optional commands.
+
+
+Postel & Reynolds                                               [Page 2]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      In particular, the following new optional commands are included in
+      this edition of the specification:
+
+         CDUP - Change to Parent Directory
+
+         SMNT - Structure Mount
+
+         STOU - Store Unique
+
+         RMD - Remove Directory
+
+         MKD - Make Directory
+
+         PWD - Print Directory
+
+         SYST - System
+
+      This specification is compatible with the previous edition.  A
+      program implemented in conformance to the previous specification
+      should automatically be in conformance to this specification.
+
+   2.2.  TERMINOLOGY
+
+      ASCII
+
+         The ASCII character set is as defined in the ARPA-Internet
+         Protocol Handbook.  In FTP, ASCII characters are defined to be
+         the lower half of an eight-bit code set (i.e., the most
+         significant bit is zero).
+
+      access controls
+
+         Access controls define users' access privileges to the use of a
+         system, and to the files in that system.  Access controls are
+         necessary to prevent unauthorized or accidental use of files.
+         It is the prerogative of a server-FTP process to invoke access
+         controls.
+
+      byte size
+
+         There are two byte sizes of interest in FTP:  the logical byte
+         size of the file, and the transfer byte size used for the
+         transmission of the data.  The transfer byte size is always 8
+         bits.  The transfer byte size is not necessarily the byte size
+         in which data is to be stored in a system, nor the logical byte
+         size for interpretation of the structure of the data.
+
+
+
+Postel & Reynolds                                               [Page 3]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      control connection
+
+         The communication path between the USER-PI and SERVER-PI for
+         the exchange of commands and replies.  This connection follows
+         the Telnet Protocol.
+
+      data connection
+
+         A full duplex connection over which data is transferred, in a
+         specified mode and type. The data transferred may be a part of
+         a file, an entire file or a number of files.  The path may be
+         between a server-DTP and a user-DTP, or between two
+         server-DTPs.
+
+      data port
+
+         The passive data transfer process "listens" on the data port
+         for a connection from the active transfer process in order to
+         open the data connection.
+
+      DTP
+
+         The data transfer process establishes and manages the data
+         connection.  The DTP can be passive or active.
+
+      End-of-Line
+
+         The end-of-line sequence defines the separation of printing
+         lines.  The sequence is Carriage Return, followed by Line Feed.
+
+      EOF
+
+         The end-of-file condition that defines the end of a file being
+         transferred.
+
+      EOR
+
+         The end-of-record condition that defines the end of a record
+         being transferred.
+
+      error recovery
+
+         A procedure that allows a user to recover from certain errors
+         such as failure of either host system or transfer process.  In
+         FTP, error recovery may involve restarting a file transfer at a
+         given checkpoint.
+
+
+
+Postel & Reynolds                                               [Page 4]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      FTP commands
+
+         A set of commands that comprise the control information flowing
+         from the user-FTP to the server-FTP process.
+
+      file
+
+         An ordered set of computer data (including programs), of
+         arbitrary length, uniquely identified by a pathname.
+
+      mode
+
+         The mode in which data is to be transferred via the data
+         connection.  The mode defines the data format during transfer
+         including EOR and EOF.  The transfer modes defined in FTP are
+         described in the Section on Transmission Modes.
+
+      NVT
+
+         The Network Virtual Terminal as defined in the Telnet Protocol.
+
+      NVFS
+
+         The Network Virtual File System.  A concept which defines a
+         standard network file system with standard commands and
+         pathname conventions.
+
+      page
+
+         A file may be structured as a set of independent parts called
+         pages.  FTP supports the transmission of discontinuous files as
+         independent indexed pages.
+
+      pathname
+
+         Pathname is defined to be the character string which must be
+         input to a file system by a user in order to identify a file.
+         Pathname normally contains device and/or directory names, and
+         file name specification.  FTP does not yet specify a standard
+         pathname convention.  Each user must follow the file naming
+         conventions of the file systems involved in the transfer.
+
+      PI
+
+         The protocol interpreter.  The user and server sides of the
+         protocol have distinct roles implemented in a user-PI and a
+         server-PI.
+
+
+Postel & Reynolds                                               [Page 5]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      record
+
+         A sequential file may be structured as a number of contiguous
+         parts called records.  Record structures are supported by FTP
+         but a file need not have record structure.
+
+      reply
+
+         A reply is an acknowledgment (positive or negative) sent from
+         server to user via the control connection in response to FTP
+         commands.  The general form of a reply is a completion code
+         (including error codes) followed by a text string.  The codes
+         are for use by programs and the text is usually intended for
+         human users.
+
+      server-DTP
+
+         The data transfer process, in its normal "active" state,
+         establishes the data connection with the "listening" data port.
+         It sets up parameters for transfer and storage, and transfers
+         data on command from its PI.  The DTP can be placed in a
+         "passive" state to listen for, rather than initiate a
+         connection on the data port.
+
+      server-FTP process
+
+         A process or set of processes which perform the function of
+         file transfer in cooperation with a user-FTP process and,
+         possibly, another server.  The functions consist of a protocol
+         interpreter (PI) and a data transfer process (DTP).
+
+      server-PI
+
+         The server protocol interpreter "listens" on Port L for a
+         connection from a user-PI and establishes a control
+         communication connection.  It receives standard FTP commands
+         from the user-PI, sends replies, and governs the server-DTP.
+
+      type
+
+         The data representation type used for data transfer and
+         storage.  Type implies certain transformations between the time
+         of data storage and data transfer.  The representation types
+         defined in FTP are described in the Section on Establishing
+         Data Connections.
+
+
+
+
+Postel & Reynolds                                               [Page 6]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      user
+
+         A person or a process on behalf of a person wishing to obtain
+         file transfer service.  The human user may interact directly
+         with a server-FTP process, but use of a user-FTP process is
+         preferred since the protocol design is weighted towards
+         automata.
+
+      user-DTP
+
+         The data transfer process "listens" on the data port for a
+         connection from a server-FTP process.  If two servers are
+         transferring data between them, the user-DTP is inactive.
+
+      user-FTP process
+
+         A set of functions including a protocol interpreter, a data
+         transfer process and a user interface which together perform
+         the function of file transfer in cooperation with one or more
+         server-FTP processes.  The user interface allows a local
+         language to be used in the command-reply dialogue with the
+         user.
+
+      user-PI
+
+         The user protocol interpreter initiates the control connection
+         from its port U to the server-FTP process, initiates FTP
+         commands, and governs the user-DTP if that process is part of
+         the file transfer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                               [Page 7]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   2.3.  THE FTP MODEL
+
+      With the above definitions in mind, the following model (shown in
+      Figure 1) may be diagrammed for an FTP service.
+
+                                            -------------
+                                            |/---------\|
+                                            ||   User  ||    --------
+                                            ||Interface|<--->| User |
+                                            |\----^----/|    --------
+                  ----------                |     |     |
+                  |/------\|  FTP Commands  |/----V----\|
+                  ||Server|<---------------->|   User  ||
+                  ||  PI  ||   FTP Replies  ||    PI   ||
+                  |\--^---/|                |\----^----/|
+                  |   |    |                |     |     |
+      --------    |/--V---\|      Data      |/----V----\|    --------
+      | File |<--->|Server|<---------------->|  User   |<--->| File |
+      |System|    || DTP  ||   Connection   ||   DTP   ||    |System|
+      --------    |\------/|                |\---------/|    --------
+                  ----------                -------------
+
+                  Server-FTP                   USER-FTP
+
+      NOTES: 1. The data connection may be used in either direction.
+             2. The data connection need not exist all of the time.
+
+                      Figure 1  Model for FTP Use
+
+      In the model described in Figure 1, the user-protocol interpreter
+      initiates the control connection.  The control connection follows
+      the Telnet protocol.  At the initiation of the user, standard FTP
+      commands are generated by the user-PI and transmitted to the
+      server process via the control connection.  (The user may
+      establish a direct control connection to the server-FTP, from a
+      TAC terminal for example, and generate standard FTP commands
+      independently, bypassing the user-FTP process.) Standard replies
+      are sent from the server-PI to the user-PI over the control
+      connection in response to the commands.
+
+      The FTP commands specify the parameters for the data connection
+      (data port, transfer mode, representation type, and structure) and
+      the nature of file system operation (store, retrieve, append,
+      delete, etc.).  The user-DTP or its designate should "listen" on
+      the specified data port, and the server initiate the data
+      connection and data transfer in accordance with the specified
+      parameters.  It should be noted that the data port need not be in
+
+
+Postel & Reynolds                                               [Page 8]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      the same host that initiates the FTP commands via the control
+      connection, but the user or the user-FTP process must ensure a
+      "listen" on the specified data port.  It ought to also be noted
+      that the data connection may be used for simultaneous sending and
+      receiving.
+
+      In another situation a user might wish to transfer files between
+      two hosts, neither of which is a local host. The user sets up
+      control connections to the two servers and then arranges for a
+      data connection between them.  In this manner, control information
+      is passed to the user-PI but data is transferred between the
+      server data transfer processes.  Following is a model of this
+      server-server interaction.
+
+      
+                    Control     ------------   Control
+                    ---------->| User-FTP |<-----------
+                    |          | User-PI  |           |
+                    |          |   "C"    |           |
+                    V          ------------           V
+            --------------                        --------------
+            | Server-FTP |   Data Connection      | Server-FTP |
+            |    "A"     |<---------------------->|    "B"     |
+            -------------- Port (A)      Port (B) --------------
+      
+
+                                 Figure 2
+
+      The protocol requires that the control connections be open while
+      data transfer is in progress.  It is the responsibility of the
+      user to request the closing of the control connections when
+      finished using the FTP service, while it is the server who takes
+      the action.  The server may abort data transfer if the control
+      connections are closed without command.
+
+      The Relationship between FTP and Telnet:
+
+         The FTP uses the Telnet protocol on the control connection.
+         This can be achieved in two ways: first, the user-PI or the
+         server-PI may implement the rules of the Telnet Protocol
+         directly in their own procedures; or, second, the user-PI or
+         the server-PI may make use of the existing Telnet module in the
+         system.
+
+         Ease of implementaion, sharing code, and modular programming
+         argue for the second approach.  Efficiency and independence
+
+
+
+Postel & Reynolds                                               [Page 9]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         argue for the first approach.  In practice, FTP relies on very
+         little of the Telnet Protocol, so the first approach does not
+         necessarily involve a large amount of code.
+
+3.  DATA TRANSFER FUNCTIONS
+
+   Files are transferred only via the data connection.  The control
+   connection is used for the transfer of commands, which describe the
+   functions to be performed, and the replies to these commands (see the
+   Section on FTP Replies).  Several commands are concerned with the
+   transfer of data between hosts.  These data transfer commands include
+   the MODE command which specify how the bits of the data are to be
+   transmitted, and the STRUcture and TYPE commands, which are used to
+   define the way in which the data are to be represented.  The
+   transmission and representation are basically independent but the
+   "Stream" transmission mode is dependent on the file structure
+   attribute and if "Compressed" transmission mode is used, the nature
+   of the filler byte depends on the representation type.
+
+   3.1.  DATA REPRESENTATION AND STORAGE
+
+      Data is transferred from a storage device in the sending host to a
+      storage device in the receiving host.  Often it is necessary to
+      perform certain transformations on the data because data storage
+      representations in the two systems are different.  For example,
+      NVT-ASCII has different data storage representations in different
+      systems.  DEC TOPS-20s's generally store NVT-ASCII as five 7-bit
+      ASCII characters, left-justified in a 36-bit word. IBM Mainframe's
+      store NVT-ASCII as 8-bit EBCDIC codes.  Multics stores NVT-ASCII
+      as four 9-bit characters in a 36-bit word.  It is desirable to
+      convert characters into the standard NVT-ASCII representation when
+      transmitting text between dissimilar systems.  The sending and
+      receiving sites would have to perform the necessary
+      transformations between the standard representation and their
+      internal representations.
+
+      A different problem in representation arises when transmitting
+      binary data (not character codes) between host systems with
+      different word lengths.  It is not always clear how the sender
+      should send data, and the receiver store it.  For example, when
+      transmitting 32-bit bytes from a 32-bit word-length system to a
+      36-bit word-length system, it may be desirable (for reasons of
+      efficiency and usefulness) to store the 32-bit bytes
+      right-justified in a 36-bit word in the latter system.  In any
+      case, the user should have the option of specifying data
+      representation and transformation functions.  It should be noted
+
+
+
+Postel & Reynolds                                              [Page 10]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      that FTP provides for very limited data type representations.
+      Transformations desired beyond this limited capability should be
+      performed by the user directly.
+
+      3.1.1.  DATA TYPES
+
+         Data representations are handled in FTP by a user specifying a
+         representation type.  This type may implicitly (as in ASCII or
+         EBCDIC) or explicitly (as in Local byte) define a byte size for
+         interpretation which is referred to as the "logical byte size."
+         Note that this has nothing to do with the byte size used for
+         transmission over the data connection, called the "transfer
+         byte size", and the two should not be confused.  For example,
+         NVT-ASCII has a logical byte size of 8 bits.  If the type is
+         Local byte, then the TYPE command has an obligatory second
+         parameter specifying the logical byte size.  The transfer byte
+         size is always 8 bits.
+
+         3.1.1.1.  ASCII TYPE
+
+            This is the default type and must be accepted by all FTP
+            implementations.  It is intended primarily for the transfer
+            of text files, except when both hosts would find the EBCDIC
+            type more convenient.
+
+            The sender converts the data from an internal character
+            representation to the standard 8-bit NVT-ASCII
+            representation (see the Telnet specification).  The receiver
+            will convert the data from the standard form to his own
+            internal form.
+
+            In accordance with the NVT standard, the <CRLF> sequence
+            should be used where necessary to denote the end of a line
+            of text.  (See the discussion of file structure at the end
+            of the Section on Data Representation and Storage.)
+
+            Using the standard NVT-ASCII representation means that data
+            must be interpreted as 8-bit bytes.
+
+            The Format parameter for ASCII and EBCDIC types is discussed
+            below.
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 11]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         3.1.1.2.  EBCDIC TYPE
+
+            This type is intended for efficient transfer between hosts
+            which use EBCDIC for their internal character
+            representation.
+
+            For transmission, the data are represented as 8-bit EBCDIC
+            characters.  The character code is the only difference
+            between the functional specifications of EBCDIC and ASCII
+            types.
+
+            End-of-line (as opposed to end-of-record--see the discussion
+            of structure) will probably be rarely used with EBCDIC type
+            for purposes of denoting structure, but where it is
+            necessary the <NL> character should be used.
+
+         3.1.1.3.  IMAGE TYPE
+
+            The data are sent as contiguous bits which, for transfer,
+            are packed into the 8-bit transfer bytes.  The receiving
+            site must store the data as contiguous bits.  The structure
+            of the storage system might necessitate the padding of the
+            file (or of each record, for a record-structured file) to
+            some convenient boundary (byte, word or block).  This
+            padding, which must be all zeros, may occur only at the end
+            of the file (or at the end of each record) and there must be
+            a way of identifying the padding bits so that they may be
+            stripped off if the file is retrieved.  The padding
+            transformation should be well publicized to enable a user to
+            process a file at the storage site.
+
+            Image type is intended for the efficient storage and
+            retrieval of files and for the transfer of binary data.  It
+            is recommended that this type be accepted by all FTP
+            implementations.
+
+         3.1.1.4.  LOCAL TYPE
+
+            The data is transferred in logical bytes of the size
+            specified by the obligatory second parameter, Byte size.
+            The value of Byte size must be a decimal integer; there is
+            no default value.  The logical byte size is not necessarily
+            the same as the transfer byte size.  If there is a
+            difference in byte sizes, then the logical bytes should be
+            packed contiguously, disregarding transfer byte boundaries
+            and with any necessary padding at the end.
+
+
+
+Postel & Reynolds                                              [Page 12]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+            When the data reaches the receiving host, it will be
+            transformed in a manner dependent on the logical byte size
+            and the particular host.  This transformation must be
+            invertible (i.e., an identical file can be retrieved if the
+            same parameters are used) and should be well publicized by
+            the FTP implementors.
+
+            For example, a user sending 36-bit floating-point numbers to
+            a host with a 32-bit word could send that data as Local byte
+            with a logical byte size of 36.  The receiving host would
+            then be expected to store the logical bytes so that they
+            could be easily manipulated; in this example putting the
+            36-bit logical bytes into 64-bit double words should
+            suffice.
+
+            In another example, a pair of hosts with a 36-bit word size
+            may send data to one another in words by using TYPE L 36.
+            The data would be sent in the 8-bit transmission bytes
+            packed so that 9 transmission bytes carried two host words.
+
+         3.1.1.5.  FORMAT CONTROL
+
+            The types ASCII and EBCDIC also take a second (optional)
+            parameter; this is to indicate what kind of vertical format
+            control, if any, is associated with a file.  The following
+            data representation types are defined in FTP:
+
+            A character file may be transferred to a host for one of
+            three purposes: for printing, for storage and later
+            retrieval, or for processing.  If a file is sent for
+            printing, the receiving host must know how the vertical
+            format control is represented.  In the second case, it must
+            be possible to store a file at a host and then retrieve it
+            later in exactly the same form.  Finally, it should be
+            possible to move a file from one host to another and process
+            the file at the second host without undue trouble.  A single
+            ASCII or EBCDIC format does not satisfy all these
+            conditions.  Therefore, these types have a second parameter
+            specifying one of the following three formats:
+
+            3.1.1.5.1.  NON PRINT
+
+               This is the default format to be used if the second
+               (format) parameter is omitted.  Non-print format must be
+               accepted by all FTP implementations.
+
+
+
+
+Postel & Reynolds                                              [Page 13]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+               The file need contain no vertical format information.  If
+               it is passed to a printer process, this process may
+               assume standard values for spacing and margins.
+
+               Normally, this format will be used with files destined
+               for processing or just storage.
+
+            3.1.1.5.2.  TELNET FORMAT CONTROLS
+
+               The file contains ASCII/EBCDIC vertical format controls
+               (i.e., <CR>, <LF>, <NL>, <VT>, <FF>) which the printer
+               process will interpret appropriately.  <CRLF>, in exactly
+               this sequence, also denotes end-of-line.
+
+            3.1.1.5.2.  CARRIAGE CONTROL (ASA)
+
+               The file contains ASA (FORTRAN) vertical format control
+               characters.  (See RFC 740 Appendix C; and Communications
+               of the ACM, Vol. 7, No. 10, p. 606, October 1964.)  In a
+               line or a record formatted according to the ASA Standard,
+               the first character is not to be printed.  Instead, it
+               should be used to determine the vertical movement of the
+               paper which should take place before the rest of the
+               record is printed.
+
+               The ASA Standard specifies the following control
+               characters:
+
+                  Character     Vertical Spacing
+
+                  blank         Move paper up one line
+                  0             Move paper up two lines
+                  1             Move paper to top of next page
+                  +             No movement, i.e., overprint
+
+               Clearly there must be some way for a printer process to
+               distinguish the end of the structural entity.  If a file
+               has record structure (see below) this is no problem;
+               records will be explicitly marked during transfer and
+               storage.  If the file has no record structure, the <CRLF>
+               end-of-line sequence is used to separate printing lines,
+               but these format effectors are overridden by the ASA
+               controls.
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 14]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      3.1.2.  DATA STRUCTURES
+
+         In addition to different representation types, FTP allows the
+         structure of a file to be specified.  Three file structures are
+         defined in FTP:
+
+            file-structure,     where there is no internal structure and
+                                the file is considered to be a
+                                continuous sequence of data bytes,
+
+            record-structure,   where the file is made up of sequential
+                                records,
+
+            and page-structure, where the file is made up of independent
+                                indexed pages.
+
+         File-structure is the default to be assumed if the STRUcture
+         command has not been used but both file and record structures
+         must be accepted for "text" files (i.e., files with TYPE ASCII
+         or EBCDIC) by all FTP implementations.  The structure of a file
+         will affect both the transfer mode of a file (see the Section
+         on Transmission Modes) and the interpretation and storage of
+         the file.
+
+         The "natural" structure of a file will depend on which host
+         stores the file.  A source-code file will usually be stored on
+         an IBM Mainframe in fixed length records but on a DEC TOPS-20
+         as a stream of characters partitioned into lines, for example
+         by <CRLF>.  If the transfer of files between such disparate
+         sites is to be useful, there must be some way for one site to
+         recognize the other's assumptions about the file.
+
+         With some sites being naturally file-oriented and others
+         naturally record-oriented there may be problems if a file with
+         one structure is sent to a host oriented to the other.  If a
+         text file is sent with record-structure to a host which is file
+         oriented, then that host should apply an internal
+         transformation to the file based on the record structure.
+         Obviously, this transformation should be useful, but it must
+         also be invertible so that an identical file may be retrieved
+         using record structure.
+
+         In the case of a file being sent with file-structure to a
+         record-oriented host, there exists the question of what
+         criteria the host should use to divide the file into records
+         which can be processed locally.  If this division is necessary,
+         the FTP implementation should use the end-of-line sequence,
+
+
+Postel & Reynolds                                              [Page 15]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         <CRLF> for ASCII, or <NL> for EBCDIC text files, as the
+         delimiter.  If an FTP implementation adopts this technique, it
+         must be prepared to reverse the transformation if the file is
+         retrieved with file-structure.
+
+         3.1.2.1.  FILE STRUCTURE
+
+            File structure is the default to be assumed if the STRUcture
+            command has not been used.
+
+            In file-structure there is no internal structure and the
+            file is considered to be a continuous sequence of data
+            bytes.
+
+         3.1.2.2.  RECORD STRUCTURE
+
+            Record structures must be accepted for "text" files (i.e.,
+            files with TYPE ASCII or EBCDIC) by all FTP implementations.
+
+            In record-structure the file is made up of sequential
+            records.
+
+         3.1.2.3.  PAGE STRUCTURE
+
+            To transmit files that are discontinuous, FTP defines a page
+            structure.  Files of this type are sometimes known as
+            "random access files" or even as "holey files".  In these
+            files there is sometimes other information associated with
+            the file as a whole (e.g., a file descriptor), or with a
+            section of the file (e.g., page access controls), or both.
+            In FTP, the sections of the file are called pages.
+
+            To provide for various page sizes and associated
+            information, each page is sent with a page header.  The page
+            header has the following defined fields:
+
+               Header Length
+
+                  The number of logical bytes in the page header
+                  including this byte.  The minimum header length is 4.
+
+               Page Index
+
+                  The logical page number of this section of the file.
+                  This is not the transmission sequence number of this
+                  page, but the index used to identify this page of the
+                  file.
+
+
+Postel & Reynolds                                              [Page 16]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+               Data Length
+
+                  The number of logical bytes in the page data.  The
+                  minimum data length is 0.
+
+               Page Type
+
+                  The type of page this is.  The following page types
+                  are defined:
+
+                     0 = Last Page
+
+                        This is used to indicate the end of a paged
+                        structured transmission.  The header length must
+                        be 4, and the data length must be 0.
+
+                     1 = Simple Page
+
+                        This is the normal type for simple paged files
+                        with no page level associated control
+                        information.  The header length must be 4.
+
+                     2 = Descriptor Page
+
+                        This type is used to transmit the descriptive
+                        information for the file as a whole.
+
+                     3 = Access Controlled Page
+
+                        This type includes an additional header field
+                        for paged files with page level access control
+                        information.  The header length must be 5.
+
+               Optional Fields
+
+                  Further header fields may be used to supply per page
+                  control information, for example, per page access
+                  control.
+
+            All fields are one logical byte in length.  The logical byte
+            size is specified by the TYPE command.  See Appendix I for
+            further details and a specific case at the page structure.
+
+      A note of caution about parameters:  a file must be stored and
+      retrieved with the same parameters if the retrieved version is to
+
+
+
+
+Postel & Reynolds                                              [Page 17]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      be identical to the version originally transmitted.  Conversely,
+      FTP implementations must return a file identical to the original
+      if the parameters used to store and retrieve a file are the same.
+
+   3.2.  ESTABLISHING DATA CONNECTIONS
+
+      The mechanics of transferring data consists of setting up the data
+      connection to the appropriate ports and choosing the parameters
+      for transfer.  Both the user and the server-DTPs have a default
+      data port.  The user-process default data port is the same as the
+      control connection port (i.e., U).  The server-process default
+      data port is the port adjacent to the control connection port
+      (i.e., L-1).
+
+      The transfer byte size is 8-bit bytes.  This byte size is relevant
+      only for the actual transfer of the data; it has no bearing on
+      representation of the data within a host's file system.
+
+      The passive data transfer process (this may be a user-DTP or a
+      second server-DTP) shall "listen" on the data port prior to
+      sending a transfer request command.  The FTP request command
+      determines the direction of the data transfer.  The server, upon
+      receiving the transfer request, will initiate the data connection
+      to the port.  When the connection is established, the data
+      transfer begins between DTP's, and the server-PI sends a
+      confirming reply to the user-PI.
+
+      Every FTP implementation must support the use of the default data
+      ports, and only the USER-PI can initiate a change to non-default
+      ports.
+
+      It is possible for the user to specify an alternate data port by
+      use of the PORT command.  The user may want a file dumped on a TAC
+      line printer or retrieved from a third party host.  In the latter
+      case, the user-PI sets up control connections with both
+      server-PI's.  One server is then told (by an FTP command) to
+      "listen" for a connection which the other will initiate.  The
+      user-PI sends one server-PI a PORT command indicating the data
+      port of the other.  Finally, both are sent the appropriate
+      transfer commands.  The exact sequence of commands and replies
+      sent between the user-controller and the servers is defined in the
+      Section on FTP Replies.
+
+      In general, it is the server's responsibility to maintain the data
+      connection--to initiate it and to close it.  The exception to this
+
+
+
+
+Postel & Reynolds                                              [Page 18]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      is when the user-DTP is sending the data in a transfer mode that
+      requires the connection to be closed to indicate EOF.  The server
+      MUST close the data connection under the following conditions:
+
+         1. The server has completed sending data in a transfer mode
+            that requires a close to indicate EOF.
+
+         2. The server receives an ABORT command from the user.
+
+         3. The port specification is changed by a command from the
+            user.
+
+         4. The control connection is closed legally or otherwise.
+
+         5. An irrecoverable error condition occurs.
+
+      Otherwise the close is a server option, the exercise of which the
+      server must indicate to the user-process by either a 250 or 226
+      reply only.
+
+   3.3.  DATA CONNECTION MANAGEMENT
+
+      Default Data Connection Ports:  All FTP implementations must
+      support use of the default data connection ports, and only the
+      User-PI may initiate the use of non-default ports.
+
+      Negotiating Non-Default Data Ports:   The User-PI may specify a
+      non-default user side data port with the PORT command.  The
+      User-PI may request the server side to identify a non-default
+      server side data port with the PASV command.  Since a connection
+      is defined by the pair of addresses, either of these actions is
+      enough to get a different data connection, still it is permitted
+      to do both commands to use new ports on both ends of the data
+      connection.
+
+      Reuse of the Data Connection:  When using the stream mode of data
+      transfer the end of the file must be indicated by closing the
+      connection.  This causes a problem if multiple files are to be
+      transfered in the session, due to need for TCP to hold the
+      connection record for a time out period to guarantee the reliable
+      communication.  Thus the connection can not be reopened at once.
+
+         There are two solutions to this problem.  The first is to
+         negotiate a non-default port.  The second is to use another
+         transfer mode.
+
+         A comment on transfer modes.  The stream transfer mode is
+
+
+Postel & Reynolds                                              [Page 19]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         inherently unreliable, since one can not determine if the
+         connection closed prematurely or not.  The other transfer modes
+         (Block, Compressed) do not close the connection to indicate the
+         end of file.  They have enough FTP encoding that the data
+         connection can be parsed to determine the end of the file.
+         Thus using these modes one can leave the data connection open
+         for multiple file transfers.
+
+   3.4.  TRANSMISSION MODES
+
+      The next consideration in transferring data is choosing the
+      appropriate transmission mode.  There are three modes: one which
+      formats the data and allows for restart procedures; one which also
+      compresses the data for efficient transfer; and one which passes
+      the data with little or no processing.  In this last case the mode
+      interacts with the structure attribute to determine the type of
+      processing.  In the compressed mode, the representation type
+      determines the filler byte.
+
+      All data transfers must be completed with an end-of-file (EOF)
+      which may be explicitly stated or implied by the closing of the
+      data connection.  For files with record structure, all the
+      end-of-record markers (EOR) are explicit, including the final one.
+      For files transmitted in page structure a "last-page" page type is
+      used.
+
+      NOTE:  In the rest of this section, byte means "transfer byte"
+      except where explicitly stated otherwise.
+
+      For the purpose of standardized transfer, the sending host will
+      translate its internal end of line or end of record denotation
+      into the representation prescribed by the transfer mode and file
+      structure, and the receiving host will perform the inverse
+      translation to its internal denotation.  An IBM Mainframe record
+      count field may not be recognized at another host, so the
+      end-of-record information may be transferred as a two byte control
+      code in Stream mode or as a flagged bit in a Block or Compressed
+      mode descriptor.  End-of-line in an ASCII or EBCDIC file with no
+      record structure should be indicated by <CRLF> or <NL>,
+      respectively.  Since these transformations imply extra work for
+      some systems, identical systems transferring non-record structured
+      text files might wish to use a binary representation and stream
+      mode for the transfer.
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 20]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      The following transmission modes are defined in FTP:
+
+      3.4.1.  STREAM MODE
+
+         The data is transmitted as a stream of bytes.  There is no
+         restriction on the representation type used; record structures
+         are allowed.
+
+         In a record structured file EOR and EOF will each be indicated
+         by a two-byte control code.  The first byte of the control code
+         will be all ones, the escape character.  The second byte will
+         have the low order bit on and zeros elsewhere for EOR and the
+         second low order bit on for EOF; that is, the byte will have
+         value 1 for EOR and value 2 for EOF.  EOR and EOF may be
+         indicated together on the last byte transmitted by turning both
+         low order bits on (i.e., the value 3).  If a byte of all ones
+         was intended to be sent as data, it should be repeated in the
+         second byte of the control code.
+
+         If the structure is a file structure, the EOF is indicated by
+         the sending host closing the data connection and all bytes are
+         data bytes.
+
+      3.4.2.  BLOCK MODE
+
+         The file is transmitted as a series of data blocks preceded by
+         one or more header bytes.  The header bytes contain a count
+         field, and descriptor code.  The count field indicates the
+         total length of the data block in bytes, thus marking the
+         beginning of the next data block (there are no filler bits).
+         The descriptor code defines:  last block in the file (EOF) last
+         block in the record (EOR), restart marker (see the Section on
+         Error Recovery and Restart) or suspect data (i.e., the data
+         being transferred is suspected of errors and is not reliable).
+         This last code is NOT intended for error control within FTP.
+         It is motivated by the desire of sites exchanging certain types
+         of data (e.g., seismic or weather data) to send and receive all
+         the data despite local errors (such as "magnetic tape read
+         errors"), but to indicate in the transmission that certain
+         portions are suspect).  Record structures are allowed in this
+         mode, and any representation type may be used.
+
+         The header consists of the three bytes.  Of the 24 bits of
+         header information, the 16 low order bits shall represent byte
+         count, and the 8 high order bits shall represent descriptor
+         codes as shown below.
+
+
+
+Postel & Reynolds                                              [Page 21]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         Block Header
+
+            +----------------+----------------+----------------+
+            | Descriptor     |    Byte Count                   |
+            |         8 bits |                      16 bits    |
+            +----------------+----------------+----------------+
+            
+
+         The descriptor codes are indicated by bit flags in the
+         descriptor byte.  Four codes have been assigned, where each
+         code number is the decimal value of the corresponding bit in
+         the byte.
+
+            Code     Meaning
+            
+             128     End of data block is EOR
+              64     End of data block is EOF
+              32     Suspected errors in data block
+              16     Data block is a restart marker
+
+         With this encoding, more than one descriptor coded condition
+         may exist for a particular block.  As many bits as necessary
+         may be flagged.
+
+         The restart marker is embedded in the data stream as an
+         integral number of 8-bit bytes representing printable
+         characters in the language being used over the control
+         connection (e.g., default--NVT-ASCII).  <SP> (Space, in the
+         appropriate language) must not be used WITHIN a restart marker.
+
+         For example, to transmit a six-character marker, the following
+         would be sent:
+
+            +--------+--------+--------+
+            |Descrptr|  Byte count     |
+            |code= 16|             = 6 |
+            +--------+--------+--------+
+
+            +--------+--------+--------+
+            | Marker | Marker | Marker |
+            | 8 bits | 8 bits | 8 bits |
+            +--------+--------+--------+
+
+            +--------+--------+--------+
+            | Marker | Marker | Marker |
+            | 8 bits | 8 bits | 8 bits |
+            +--------+--------+--------+
+
+
+Postel & Reynolds                                              [Page 22]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      3.4.3.  COMPRESSED MODE
+
+         There are three kinds of information to be sent:  regular data,
+         sent in a byte string; compressed data, consisting of
+         replications or filler; and control information, sent in a
+         two-byte escape sequence.  If n>0 bytes (up to 127) of regular
+         data are sent, these n bytes are preceded by a byte with the
+         left-most bit set to 0 and the right-most 7 bits containing the
+         number n.
+
+         Byte string:
+
+             1       7                8                     8
+            +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
+            |0|       n     | |    d(1)       | ... |      d(n)     |
+            +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
+                                          ^             ^
+                                          |---n bytes---|
+                                              of data
+
+            String of n data bytes d(1),..., d(n)
+            Count n must be positive.
+
+         To compress a string of n replications of the data byte d, the
+         following 2 bytes are sent:
+
+         Replicated Byte:
+
+              2       6               8
+            +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
+            |1 0|     n     | |       d       |
+            +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
+
+         A string of n filler bytes can be compressed into a single
+         byte, where the filler byte varies with the representation
+         type.  If the type is ASCII or EBCDIC the filler byte is <SP>
+         (Space, ASCII code 32, EBCDIC code 64).  If the type is Image
+         or Local byte the filler is a zero byte.
+
+         Filler String:
+
+              2       6
+            +-+-+-+-+-+-+-+-+
+            |1 1|     n     |
+            +-+-+-+-+-+-+-+-+
+
+         The escape sequence is a double byte, the first of which is the
+
+
+Postel & Reynolds                                              [Page 23]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         escape byte (all zeros) and the second of which contains
+         descriptor codes as defined in Block mode.  The descriptor
+         codes have the same meaning as in Block mode and apply to the
+         succeeding string of bytes.
+
+         Compressed mode is useful for obtaining increased bandwidth on
+         very large network transmissions at a little extra CPU cost.
+         It can be most effectively used to reduce the size of printer
+         files such as those generated by RJE hosts.
+
+   3.5.  ERROR RECOVERY AND RESTART
+
+      There is no provision for detecting bits lost or scrambled in data
+      transfer; this level of error control is handled by the TCP.
+      However, a restart procedure is provided to protect users from
+      gross system failures (including failures of a host, an
+      FTP-process, or the underlying network).
+
+      The restart procedure is defined only for the block and compressed
+      modes of data transfer.  It requires the sender of data to insert
+      a special marker code in the data stream with some marker
+      information.  The marker information has meaning only to the
+      sender, but must consist of printable characters in the default or
+      negotiated language of the control connection (ASCII or EBCDIC).
+      The marker could represent a bit-count, a record-count, or any
+      other information by which a system may identify a data
+      checkpoint.  The receiver of data, if it implements the restart
+      procedure, would then mark the corresponding position of this
+      marker in the receiving system, and return this information to the
+      user.
+
+      In the event of a system failure, the user can restart the data
+      transfer by identifying the marker point with the FTP restart
+      procedure.  The following example illustrates the use of the
+      restart procedure.
+
+      The sender of the data inserts an appropriate marker block in the
+      data stream at a convenient point.  The receiving host marks the
+      corresponding data point in its file system and conveys the last
+      known sender and receiver marker information to the user, either
+      directly or over the control connection in a 110 reply (depending
+      on who is the sender).  In the event of a system failure, the user
+      or controller process restarts the server at the last server
+      marker by sending a restart command with server's marker code as
+      its argument.  The restart command is transmitted over the control
+
+
+
+
+Postel & Reynolds                                              [Page 24]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      connection and is immediately followed by the command (such as
+      RETR, STOR or LIST) which was being executed when the system
+      failure occurred.
+
+4.  FILE TRANSFER FUNCTIONS
+
+   The communication channel from the user-PI to the server-PI is
+   established as a TCP connection from the user to the standard server
+   port.  The user protocol interpreter is responsible for sending FTP
+   commands and interpreting the replies received; the server-PI
+   interprets commands, sends replies and directs its DTP to set up the
+   data connection and transfer the data.  If the second party to the
+   data transfer (the passive transfer process) is the user-DTP, then it
+   is governed through the internal protocol of the user-FTP host; if it
+   is a second server-DTP, then it is governed by its PI on command from
+   the user-PI.  The FTP replies are discussed in the next section.  In
+   the description of a few of the commands in this section, it is
+   helpful to be explicit about the possible replies.
+
+   4.1.  FTP COMMANDS
+
+      4.1.1.  ACCESS CONTROL COMMANDS
+
+         The following commands specify access control identifiers
+         (command codes are shown in parentheses).
+
+         USER NAME (USER)
+
+            The argument field is a Telnet string identifying the user.
+            The user identification is that which is required by the
+            server for access to its file system.  This command will
+            normally be the first command transmitted by the user after
+            the control connections are made (some servers may require
+            this).  Additional identification information in the form of
+            a password and/or an account command may also be required by
+            some servers.  Servers may allow a new USER command to be
+            entered at any point in order to change the access control
+            and/or accounting information.  This has the effect of
+            flushing any user, password, and account information already
+            supplied and beginning the login sequence again.  All
+            transfer parameters are unchanged and any file transfer in
+            progress is completed under the old access control
+            parameters.
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 25]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         PASSWORD (PASS)
+
+            The argument field is a Telnet string specifying the user's
+            password.  This command must be immediately preceded by the
+            user name command, and, for some sites, completes the user's
+            identification for access control.  Since password
+            information is quite sensitive, it is desirable in general
+            to "mask" it or suppress typeout.  It appears that the
+            server has no foolproof way to achieve this.  It is
+            therefore the responsibility of the user-FTP process to hide
+            the sensitive password information.
+
+         ACCOUNT (ACCT)
+
+            The argument field is a Telnet string identifying the user's
+            account.  The command is not necessarily related to the USER
+            command, as some sites may require an account for login and
+            others only for specific access, such as storing files.  In
+            the latter case the command may arrive at any time.
+
+            There are reply codes to differentiate these cases for the
+            automation: when account information is required for login,
+            the response to a successful PASSword command is reply code
+            332.  On the other hand, if account information is NOT
+            required for login, the reply to a successful PASSword
+            command is 230; and if the account information is needed for
+            a command issued later in the dialogue, the server should
+            return a 332 or 532 reply depending on whether it stores
+            (pending receipt of the ACCounT command) or discards the
+            command, respectively.
+
+         CHANGE WORKING DIRECTORY (CWD)
+
+            This command allows the user to work with a different
+            directory or dataset for file storage or retrieval without
+            altering his login or accounting information.  Transfer
+            parameters are similarly unchanged.  The argument is a
+            pathname specifying a directory or other system dependent
+            file group designator.
+
+         CHANGE TO PARENT DIRECTORY (CDUP)
+
+            This command is a special case of CWD, and is included to
+            simplify the implementation of programs for transferring
+            directory trees between operating systems having different
+
+
+
+
+Postel & Reynolds                                              [Page 26]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+            syntaxes for naming the parent directory.  The reply codes
+            shall be identical to the reply codes of CWD.  See
+            Appendix II for further details.
+
+         STRUCTURE MOUNT (SMNT)
+
+            This command allows the user to mount a different file
+            system data structure without altering his login or
+            accounting information.  Transfer parameters are similarly
+            unchanged.  The argument is a pathname specifying a
+            directory or other system dependent file group designator.
+
+         REINITIALIZE (REIN)
+
+            This command terminates a USER, flushing all I/O and account
+            information, except to allow any transfer in progress to be
+            completed.  All parameters are reset to the default settings
+            and the control connection is left open.  This is identical
+            to the state in which a user finds himself immediately after
+            the control connection is opened.  A USER command may be
+            expected to follow.
+
+         LOGOUT (QUIT)
+
+            This command terminates a USER and if file transfer is not
+            in progress, the server closes the control connection.  If
+            file transfer is in progress, the connection will remain
+            open for result response and the server will then close it.
+            If the user-process is transferring files for several USERs
+            but does not wish to close and then reopen connections for
+            each, then the REIN command should be used instead of QUIT.
+
+            An unexpected close on the control connection will cause the
+            server to take the effective action of an abort (ABOR) and a
+            logout (QUIT).
+
+      4.1.2.  TRANSFER PARAMETER COMMANDS
+
+         All data transfer parameters have default values, and the
+         commands specifying data transfer parameters are required only
+         if the default parameter values are to be changed.  The default
+         value is the last specified value, or if no value has been
+         specified, the standard default value is as stated here.  This
+         implies that the server must "remember" the applicable default
+         values.  The commands may be in any order except that they must
+         precede the FTP service request.  The following commands
+         specify data transfer parameters:
+
+
+Postel & Reynolds                                              [Page 27]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         DATA PORT (PORT)
+
+            The argument is a HOST-PORT specification for the data port
+            to be used in data connection.  There are defaults for both
+            the user and server data ports, and under normal
+            circumstances this command and its reply are not needed.  If
+            this command is used, the argument is the concatenation of a
+            32-bit internet host address and a 16-bit TCP port address.
+            This address information is broken into 8-bit fields and the
+            value of each field is transmitted as a decimal number (in
+            character string representation).  The fields are separated
+            by commas.  A port command would be:
+
+               PORT h1,h2,h3,h4,p1,p2
+
+            where h1 is the high order 8 bits of the internet host
+            address.
+
+         PASSIVE (PASV)
+
+            This command requests the server-DTP to "listen" on a data
+            port (which is not its default data port) and to wait for a
+            connection rather than initiate one upon receipt of a
+            transfer command.  The response to this command includes the
+            host and port address this server is listening on.
+
+         REPRESENTATION TYPE (TYPE)
+
+            The argument specifies the representation type as described
+            in the Section on Data Representation and Storage.  Several
+            types take a second parameter.  The first parameter is
+            denoted by a single Telnet character, as is the second
+            Format parameter for ASCII and EBCDIC; the second parameter
+            for local byte is a decimal integer to indicate Bytesize.
+            The parameters are separated by a <SP> (Space, ASCII code
+            32).
+
+            The following codes are assigned for type:
+
+                         \    /
+               A - ASCII |    | N - Non-print
+                         |-><-| T - Telnet format effectors
+               E - EBCDIC|    | C - Carriage Control (ASA)
+                         /    \
+               I - Image
+               
+               L <byte size> - Local byte Byte size
+
+
+Postel & Reynolds                                              [Page 28]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+            The default representation type is ASCII Non-print.  If the
+            Format parameter is changed, and later just the first
+            argument is changed, Format then returns to the Non-print
+            default.
+
+         FILE STRUCTURE (STRU)
+
+            The argument is a single Telnet character code specifying
+            file structure described in the Section on Data
+            Representation and Storage.
+
+            The following codes are assigned for structure:
+
+               F - File (no record structure)
+               R - Record structure
+               P - Page structure
+
+            The default structure is File.
+
+         TRANSFER MODE (MODE)
+
+            The argument is a single Telnet character code specifying
+            the data transfer modes described in the Section on
+            Transmission Modes.
+
+            The following codes are assigned for transfer modes:
+
+               S - Stream
+               B - Block
+               C - Compressed
+
+            The default transfer mode is Stream.
+
+      4.1.3.  FTP SERVICE COMMANDS
+
+         The FTP service commands define the file transfer or the file
+         system function requested by the user.  The argument of an FTP
+         service command will normally be a pathname.  The syntax of
+         pathnames must conform to server site conventions (with
+         standard defaults applicable), and the language conventions of
+         the control connection.  The suggested default handling is to
+         use the last specified device, directory or file name, or the
+         standard default defined for local users.  The commands may be
+         in any order except that a "rename from" command must be
+         followed by a "rename to" command and the restart command must
+         be followed by the interrupted service command (e.g., STOR or
+         RETR).  The data, when transferred in response to FTP service
+
+
+Postel & Reynolds                                              [Page 29]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         commands, shall always be sent over the data connection, except
+         for certain informative replies.  The following commands
+         specify FTP service requests:
+
+         RETRIEVE (RETR)
+
+            This command causes the server-DTP to transfer a copy of the
+            file, specified in the pathname, to the server- or user-DTP
+            at the other end of the data connection.  The status and
+            contents of the file at the server site shall be unaffected.
+
+         STORE (STOR)
+
+            This command causes the server-DTP to accept the data
+            transferred via the data connection and to store the data as
+            a file at the server site.  If the file specified in the
+            pathname exists at the server site, then its contents shall
+            be replaced by the data being transferred.  A new file is
+            created at the server site if the file specified in the
+            pathname does not already exist.
+
+         STORE UNIQUE (STOU)
+
+            This command behaves like STOR except that the resultant
+            file is to be created in the current directory under a name
+            unique to that directory.  The 250 Transfer Started response
+            must include the name generated.
+
+         APPEND (with create) (APPE)
+
+            This command causes the server-DTP to accept the data
+            transferred via the data connection and to store the data in
+            a file at the server site.  If the file specified in the
+            pathname exists at the server site, then the data shall be
+            appended to that file; otherwise the file specified in the
+            pathname shall be created at the server site.
+
+         ALLOCATE (ALLO)
+
+            This command may be required by some servers to reserve
+            sufficient storage to accommodate the new file to be
+            transferred.  The argument shall be a decimal integer
+            representing the number of bytes (using the logical byte
+            size) of storage to be reserved for the file.  For files
+            sent with record or page structure a maximum record or page
+            size (in logical bytes) might also be necessary; this is
+            indicated by a decimal integer in a second argument field of
+
+
+Postel & Reynolds                                              [Page 30]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+            the command.  This second argument is optional, but when
+            present should be separated from the first by the three
+            Telnet characters <SP> R <SP>.  This command shall be
+            followed by a STORe or APPEnd command.  The ALLO command
+            should be treated as a NOOP (no operation) by those servers
+            which do not require that the maximum size of the file be
+            declared beforehand, and those servers interested in only
+            the maximum record or page size should accept a dummy value
+            in the first argument and ignore it.
+
+         RESTART (REST)
+
+            The argument field represents the server marker at which
+            file transfer is to be restarted.  This command does not
+            cause file transfer but skips over the file to the specified
+            data checkpoint.  This command shall be immediately followed
+            by the appropriate FTP service command which shall cause
+            file transfer to resume.
+
+         RENAME FROM (RNFR)
+
+            This command specifies the old pathname of the file which is
+            to be renamed.  This command must be immediately followed by
+            a "rename to" command specifying the new file pathname.
+
+         RENAME TO (RNTO)
+
+            This command specifies the new pathname of the file
+            specified in the immediately preceding "rename from"
+            command.  Together the two commands cause a file to be
+            renamed.
+
+         ABORT (ABOR)
+
+            This command tells the server to abort the previous FTP
+            service command and any associated transfer of data.  The
+            abort command may require "special action", as discussed in
+            the Section on FTP Commands, to force recognition by the
+            server.  No action is to be taken if the previous command
+            has been completed (including data transfer).  The control
+            connection is not to be closed by the server, but the data
+            connection must be closed.
+
+            There are two cases for the server upon receipt of this
+            command: (1) the FTP service command was already completed,
+            or (2) the FTP service command is still in progress.
+
+
+
+Postel & Reynolds                                              [Page 31]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+               In the first case, the server closes the data connection
+               (if it is open) and responds with a 226 reply, indicating
+               that the abort command was successfully processed.
+
+               In the second case, the server aborts the FTP service in
+               progress and closes the data connection, returning a 426
+               reply to indicate that the service request terminated
+               abnormally.  The server then sends a 226 reply,
+               indicating that the abort command was successfully
+               processed.
+
+         DELETE (DELE)
+
+            This command causes the file specified in the pathname to be
+            deleted at the server site.  If an extra level of protection
+            is desired (such as the query, "Do you really wish to
+            delete?"), it should be provided by the user-FTP process.
+
+         REMOVE DIRECTORY (RMD)
+
+            This command causes the directory specified in the pathname
+            to be removed as a directory (if the pathname is absolute)
+            or as a subdirectory of the current working directory (if
+            the pathname is relative).  See Appendix II.
+
+         MAKE DIRECTORY (MKD)
+
+            This command causes the directory specified in the pathname
+            to be created as a directory (if the pathname is absolute)
+            or as a subdirectory of the current working directory (if
+            the pathname is relative).  See Appendix II.
+
+         PRINT WORKING DIRECTORY (PWD)
+
+            This command causes the name of the current working
+            directory to be returned in the reply.  See Appendix II.
+
+         LIST (LIST)
+
+            This command causes a list to be sent from the server to the
+            passive DTP.  If the pathname specifies a directory or other
+            group of files, the server should transfer a list of files
+            in the specified directory.  If the pathname specifies a
+            file then the server should send current information on the
+            file.  A null argument implies the user's current working or
+            default directory.  The data transfer is over the data
+            connection in type ASCII or type EBCDIC.  (The user must
+
+
+Postel & Reynolds                                              [Page 32]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+            ensure that the TYPE is appropriately ASCII or EBCDIC).
+            Since the information on a file may vary widely from system
+            to system, this information may be hard to use automatically
+            in a program, but may be quite useful to a human user.
+
+         NAME LIST (NLST)
+
+            This command causes a directory listing to be sent from
+            server to user site.  The pathname should specify a
+            directory or other system-specific file group descriptor; a
+            null argument implies the current directory.  The server
+            will return a stream of names of files and no other
+            information.  The data will be transferred in ASCII or
+            EBCDIC type over the data connection as valid pathname
+            strings separated by <CRLF> or <NL>.  (Again the user must
+            ensure that the TYPE is correct.)  This command is intended
+            to return information that can be used by a program to
+            further process the files automatically.  For example, in
+            the implementation of a "multiple get" function.
+
+         SITE PARAMETERS (SITE)
+
+            This command is used by the server to provide services
+            specific to his system that are essential to file transfer
+            but not sufficiently universal to be included as commands in
+            the protocol.  The nature of these services and the
+            specification of their syntax can be stated in a reply to
+            the HELP SITE command.
+
+         SYSTEM (SYST)
+
+            This command is used to find out the type of operating
+            system at the server.  The reply shall have as its first
+            word one of the system names listed in the current version
+            of the Assigned Numbers document [4].
+
+         STATUS (STAT)
+
+            This command shall cause a status response to be sent over
+            the control connection in the form of a reply.  The command
+            may be sent during a file transfer (along with the Telnet IP
+            and Synch signals--see the Section on FTP Commands) in which
+            case the server will respond with the status of the
+            operation in progress, or it may be sent between file
+            transfers.  In the latter case, the command may have an
+            argument field.  If the argument is a pathname, the command
+            is analogous to the "list" command except that data shall be
+
+
+Postel & Reynolds                                              [Page 33]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+            transferred over the control connection.  If a partial
+            pathname is given, the server may respond with a list of
+            file names or attributes associated with that specification.
+            If no argument is given, the server should return general
+            status information about the server FTP process.  This
+            should include current values of all transfer parameters and
+            the status of connections.
+
+         HELP (HELP)
+
+            This command shall cause the server to send helpful
+            information regarding its implementation status over the
+            control connection to the user.  The command may take an
+            argument (e.g., any command name) and return more specific
+            information as a response.  The reply is type 211 or 214.
+            It is suggested that HELP be allowed before entering a USER
+            command. The server may use this reply to specify
+            site-dependent parameters, e.g., in response to HELP SITE.
+
+         NOOP (NOOP)
+
+            This command does not affect any parameters or previously
+            entered commands. It specifies no action other than that the
+            server send an OK reply.
+
+   The File Transfer Protocol follows the specifications of the Telnet
+   protocol for all communications over the control connection.  Since
+   the language used for Telnet communication may be a negotiated
+   option, all references in the next two sections will be to the
+   "Telnet language" and the corresponding "Telnet end-of-line code".
+   Currently, one may take these to mean NVT-ASCII and <CRLF>.  No other
+   specifications of the Telnet protocol will be cited.
+
+   FTP commands are "Telnet strings" terminated by the "Telnet end of
+   line code".  The command codes themselves are alphabetic characters
+   terminated by the character <SP> (Space) if parameters follow and
+   Telnet-EOL otherwise.  The command codes and the semantics of
+   commands are described in this section; the detailed syntax of
+   commands is specified in the Section on Commands, the reply sequences
+   are discussed in the Section on Sequencing of Commands and Replies,
+   and scenarios illustrating the use of commands are provided in the
+   Section on Typical FTP Scenarios.
+
+   FTP commands may be partitioned as those specifying access-control
+   identifiers, data transfer parameters, or FTP service requests.
+   Certain commands (such as ABOR, STAT, QUIT) may be sent over the
+   control connection while a data transfer is in progress.  Some
+
+
+Postel & Reynolds                                              [Page 34]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   servers may not be able to monitor the control and data connections
+   simultaneously, in which case some special action will be necessary
+   to get the server's attention.  The following ordered format is
+   tentatively recommended:
+
+      1. User system inserts the Telnet "Interrupt Process" (IP) signal
+      in the Telnet stream.
+
+      2. User system sends the Telnet "Synch" signal.
+
+      3. User system inserts the command (e.g., ABOR) in the Telnet
+      stream.
+
+      4. Server PI, after receiving "IP", scans the Telnet stream for
+      EXACTLY ONE FTP command.
+
+   (For other servers this may not be necessary but the actions listed
+   above should have no unusual effect.)
+
+   4.2.  FTP REPLIES
+
+      Replies to File Transfer Protocol commands are devised to ensure
+      the synchronization of requests and actions in the process of file
+      transfer, and to guarantee that the user process always knows the
+      state of the Server.  Every command must generate at least one
+      reply, although there may be more than one; in the latter case,
+      the multiple replies must be easily distinguished.  In addition,
+      some commands occur in sequential groups, such as USER, PASS and
+      ACCT, or RNFR and RNTO.  The replies show the existence of an
+      intermediate state if all preceding commands have been successful.
+      A failure at any point in the sequence necessitates the repetition
+      of the entire sequence from the beginning.
+
+         The details of the command-reply sequence are made explicit in
+         a set of state diagrams below.
+
+      An FTP reply consists of a three digit number (transmitted as
+      three alphanumeric characters) followed by some text.  The number
+      is intended for use by automata to determine what state to enter
+      next; the text is intended for the human user.  It is intended
+      that the three digits contain enough encoded information that the
+      user-process (the User-PI) will not need to examine the text and
+      may either discard it or pass it on to the user, as appropriate.
+      In particular, the text may be server-dependent, so there are
+      likely to be varying texts for each reply code.
+
+      A reply is defined to contain the 3-digit code, followed by Space
+
+
+Postel & Reynolds                                              [Page 35]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      <SP>, followed by one line of text (where some maximum line length
+      has been specified), and terminated by the Telnet end-of-line
+      code.  There will be cases however, where the text is longer than
+      a single line.  In these cases the complete text must be bracketed
+      so the User-process knows when it may stop reading the reply (i.e.
+      stop processing input on the control connection) and go do other
+      things.  This requires a special format on the first line to
+      indicate that more than one line is coming, and another on the
+      last line to designate it as the last.  At least one of these must
+      contain the appropriate reply code to indicate the state of the
+      transaction.  To satisfy all factions, it was decided that both
+      the first and last line codes should be the same.
+
+         Thus the format for multi-line replies is that the first line
+         will begin with the exact required reply code, followed
+         immediately by a Hyphen, "-" (also known as Minus), followed by
+         text.  The last line will begin with the same code, followed
+         immediately by Space <SP>, optionally some text, and the Telnet
+         end-of-line code.
+
+            For example:
+                                123-First line
+                                Second line
+                                  234 A line beginning with numbers
+                                123 The last line
+
+         The user-process then simply needs to search for the second
+         occurrence of the same reply code, followed by <SP> (Space), at
+         the beginning of a line, and ignore all intermediary lines.  If
+         an intermediary line begins with a 3-digit number, the Server
+         must pad the front  to avoid confusion.
+
+            This scheme allows standard system routines to be used for
+            reply information (such as for the STAT reply), with
+            "artificial" first and last lines tacked on.  In rare cases
+            where these routines are able to generate three digits and a
+            Space at the beginning of any line, the beginning of each
+            text line should be offset by some neutral text, like Space.
+
+         This scheme assumes that multi-line replies may not be nested.
+
+      The three digits of the reply each have a special significance.
+      This is intended to allow a range of very simple to very
+      sophisticated responses by the user-process.  The first digit
+      denotes whether the response is good, bad or incomplete.
+      (Referring to the state diagram), an unsophisticated user-process
+      will be able to determine its next action (proceed as planned,
+
+
+Postel & Reynolds                                              [Page 36]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      redo, retrench, etc.) by simply examining this first digit.  A
+      user-process that wants to know approximately what kind of error
+      occurred (e.g. file system error, command syntax error) may
+      examine the second digit, reserving the third digit for the finest
+      gradation of information (e.g., RNTO command without a preceding
+      RNFR).
+
+         There are five values for the first digit of the reply code:
+
+            1yz   Positive Preliminary reply
+
+               The requested action is being initiated; expect another
+               reply before proceeding with a new command.  (The
+               user-process sending another command before the
+               completion reply would be in violation of protocol; but
+               server-FTP processes should queue any commands that
+               arrive while a preceding command is in progress.)  This
+               type of reply can be used to indicate that the command
+               was accepted and the user-process may now pay attention
+               to the data connections, for implementations where
+               simultaneous monitoring is difficult.  The server-FTP
+               process may send at most, one 1yz reply per command.
+
+            2yz   Positive Completion reply
+
+               The requested action has been successfully completed.  A
+               new request may be initiated.
+
+            3yz   Positive Intermediate reply
+
+               The command has been accepted, but the requested action
+               is being held in abeyance, pending receipt of further
+               information.  The user should send another command
+               specifying this information.  This reply is used in
+               command sequence groups.
+
+            4yz   Transient Negative Completion reply
+
+               The command was not accepted and the requested action did
+               not take place, but the error condition is temporary and
+               the action may be requested again.  The user should
+               return to the beginning of the command sequence, if any.
+               It is difficult to assign a meaning to "transient",
+               particularly when two distinct sites (Server- and
+               User-processes) have to agree on the interpretation.
+               Each reply in the 4yz category might have a slightly
+               different time value, but the intent is that the
+
+
+Postel & Reynolds                                              [Page 37]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+               user-process is encouraged to try again.  A rule of thumb
+               in determining if a reply fits into the 4yz or the 5yz
+               (Permanent Negative) category is that replies are 4yz if
+               the commands can be repeated without any change in
+               command form or in properties of the User or Server
+               (e.g., the command is spelled the same with the same
+               arguments used; the user does not change his file access
+               or user name; the server does not put up a new
+               implementation.)
+
+            5yz   Permanent Negative Completion reply
+
+               The command was not accepted and the requested action did
+               not take place.  The User-process is discouraged from
+               repeating the exact request (in the same sequence).  Even
+               some "permanent" error conditions can be corrected, so
+               the human user may want to direct his User-process to
+               reinitiate the command sequence by direct action at some
+               point in the future (e.g., after the spelling has been
+               changed, or the user has altered his directory status.)
+
+         The following function groupings are encoded in the second
+         digit:
+
+            x0z   Syntax - These replies refer to syntax errors,
+                  syntactically correct commands that don't fit any
+                  functional category, unimplemented or superfluous
+                  commands.
+
+            x1z   Information -  These are replies to requests for
+                  information, such as status or help.
+
+            x2z   Connections - Replies referring to the control and
+                  data connections.
+
+            x3z   Authentication and accounting - Replies for the login
+                  process and accounting procedures.
+
+            x4z   Unspecified as yet.
+
+            x5z   File system - These replies indicate the status of the
+                  Server file system vis-a-vis the requested transfer or
+                  other file system action.
+
+         The third digit gives a finer gradation of meaning in each of
+         the function categories, specified by the second digit.  The
+         list of replies below will illustrate this.  Note that the text
+
+
+Postel & Reynolds                                              [Page 38]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         associated with each reply is recommended, rather than
+         mandatory, and may even change according to the command with
+         which it is associated.  The reply codes, on the other hand,
+         must strictly follow the specifications in the last section;
+         that is, Server implementations should not invent new codes for
+         situations that are only slightly different from the ones
+         described here, but rather should adapt codes already defined.
+
+            A command such as TYPE or ALLO whose successful execution
+            does not offer the user-process any new information will
+            cause a 200 reply to be returned.  If the command is not
+            implemented by a particular Server-FTP process because it
+            has no relevance to that computer system, for example ALLO
+            at a TOPS20 site, a Positive Completion reply is still
+            desired so that the simple User-process knows it can proceed
+            with its course of action.  A 202 reply is used in this case
+            with, for example, the reply text:  "No storage allocation
+            necessary."  If, on the other hand, the command requests a
+            non-site-specific action and is unimplemented, the response
+            is 502.  A refinement of that is the 504 reply for a command
+            that is implemented, but that requests an unimplemented
+            parameter.
+
+      4.2.1  Reply Codes by Function Groups
+
+         200 Command okay.
+         500 Syntax error, command unrecognized.
+             This may include errors such as command line too long.
+         501 Syntax error in parameters or arguments.
+         202 Command not implemented, superfluous at this site.
+         502 Command not implemented.
+         503 Bad sequence of commands.
+         504 Command not implemented for that parameter.
+          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 39]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         110 Restart marker reply.
+             In this case, the text is exact and not left to the
+             particular implementation; it must read:
+                  MARK yyyy = mmmm
+             Where yyyy is User-process data stream marker, and mmmm
+             server's equivalent marker (note the spaces between markers
+             and "=").
+         211 System status, or system help reply.
+         212 Directory status.
+         213 File status.
+         214 Help message.
+             On how to use the server or the meaning of a particular
+             non-standard command.  This reply is useful only to the
+             human user.
+         215 NAME system type.
+             Where NAME is an official system name from the list in the
+             Assigned Numbers document.
+          
+         120 Service ready in nnn minutes.
+         220 Service ready for new user.
+         221 Service closing control connection.
+             Logged out if appropriate.
+         421 Service not available, closing control connection.
+             This may be a reply to any command if the service knows it
+             must shut down.
+         125 Data connection already open; transfer starting.
+         225 Data connection open; no transfer in progress.
+         425 Can't open data connection.
+         226 Closing data connection.
+             Requested file action successful (for example, file
+             transfer or file abort).
+         426 Connection closed; transfer aborted.
+         227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
+          
+         230 User logged in, proceed.
+         530 Not logged in.
+         331 User name okay, need password.
+         332 Need account for login.
+         532 Need account for storing files.
+          
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 40]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         150 File status okay; about to open data connection.
+         250 Requested file action okay, completed.
+         257 "PATHNAME" created.
+         350 Requested file action pending further information.
+         450 Requested file action not taken.
+             File unavailable (e.g., file busy).
+         550 Requested action not taken.
+             File unavailable (e.g., file not found, no access).
+         451 Requested action aborted. Local error in processing.
+         551 Requested action aborted. Page type unknown.
+         452 Requested action not taken.
+             Insufficient storage space in system.
+         552 Requested file action aborted.
+             Exceeded storage allocation (for current directory or
+             dataset).
+         553 Requested action not taken.
+             File name not allowed.
+         
+
+      4.2.2 Numeric  Order List of Reply Codes
+
+         110 Restart marker reply.
+             In this case, the text is exact and not left to the
+             particular implementation; it must read:
+                  MARK yyyy = mmmm
+             Where yyyy is User-process data stream marker, and mmmm
+             server's equivalent marker (note the spaces between markers
+             and "=").
+         120 Service ready in nnn minutes.
+         125 Data connection already open; transfer starting.
+         150 File status okay; about to open data connection.
+          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 41]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         200 Command okay.
+         202 Command not implemented, superfluous at this site.
+         211 System status, or system help reply.
+         212 Directory status.
+         213 File status.
+         214 Help message.
+             On how to use the server or the meaning of a particular
+             non-standard command.  This reply is useful only to the
+             human user.
+         215 NAME system type.
+             Where NAME is an official system name from the list in the
+             Assigned Numbers document.
+         220 Service ready for new user.
+         221 Service closing control connection.
+             Logged out if appropriate.
+         225 Data connection open; no transfer in progress.
+         226 Closing data connection.
+             Requested file action successful (for example, file
+             transfer or file abort).
+         227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
+         230 User logged in, proceed.
+         250 Requested file action okay, completed.
+         257 "PATHNAME" created.
+          
+         331 User name okay, need password.
+         332 Need account for login.
+         350 Requested file action pending further information.
+          
+         421 Service not available, closing control connection.
+             This may be a reply to any command if the service knows it
+             must shut down.
+         425 Can't open data connection.
+         426 Connection closed; transfer aborted.
+         450 Requested file action not taken.
+             File unavailable (e.g., file busy).
+         451 Requested action aborted: local error in processing.
+         452 Requested action not taken.
+             Insufficient storage space in system.
+          
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 42]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         500 Syntax error, command unrecognized.
+             This may include errors such as command line too long.
+         501 Syntax error in parameters or arguments.
+         502 Command not implemented.
+         503 Bad sequence of commands.
+         504 Command not implemented for that parameter.
+         530 Not logged in.
+         532 Need account for storing files.
+         550 Requested action not taken.
+             File unavailable (e.g., file not found, no access).
+         551 Requested action aborted: page type unknown.
+         552 Requested file action aborted.
+             Exceeded storage allocation (for current directory or
+             dataset).
+         553 Requested action not taken.
+             File name not allowed.
+         
+
+5.  DECLARATIVE SPECIFICATIONS
+
+   5.1.  MINIMUM IMPLEMENTATION
+
+      In order to make FTP workable without needless error messages, the
+      following minimum implementation is required for all servers:
+
+         TYPE - ASCII Non-print
+         MODE - Stream
+         STRUCTURE - File, Record
+         COMMANDS - USER, QUIT, PORT,
+                    TYPE, MODE, STRU,
+                      for the default values
+                    RETR, STOR,
+                    NOOP.
+
+      The default values for transfer parameters are:
+
+         TYPE - ASCII Non-print
+         MODE - Stream
+         STRU - File
+
+      All hosts must accept the above as the standard defaults.
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 43]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   5.2.  CONNECTIONS
+
+      The server protocol interpreter shall "listen" on Port L.  The
+      user or user protocol interpreter shall initiate the full-duplex
+      control connection.  Server- and user- processes should follow the
+      conventions of the Telnet protocol as specified in the
+      ARPA-Internet Protocol Handbook [1].  Servers are under no
+      obligation to provide for editing of command lines and may require
+      that it be done in the user host.  The control connection shall be
+      closed by the server at the user's request after all transfers and
+      replies are completed.
+
+      The user-DTP must "listen" on the specified data port; this may be
+      the default user port (U) or a port specified in the PORT command.
+      The server shall initiate the data connection from his own default
+      data port (L-1) using the specified user data port.  The direction
+      of the transfer and the port used will be determined by the FTP
+      service command.
+
+      Note that all FTP implementation must support data transfer using
+      the default port, and that only the USER-PI may initiate the use
+      of non-default ports.
+
+      When data is to be transferred between two servers, A and B (refer
+      to Figure 2), the user-PI, C, sets up control connections with
+      both server-PI's.  One of the servers, say A, is then sent a PASV
+      command telling him to "listen" on his data port rather than
+      initiate a connection when he receives a transfer service command.
+      When the user-PI receives an acknowledgment to the PASV command,
+      which includes the identity of the host and port being listened
+      on, the user-PI then sends A's port, a, to B in a PORT command; a
+      reply is returned.  The user-PI may then send the corresponding
+      service commands to A and B.  Server B initiates the connection
+      and the transfer proceeds.  The command-reply sequence is listed
+      below where the messages are vertically synchronous but
+      horizontally asynchronous:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 44]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         User-PI - Server A                User-PI - Server B
+         ------------------                ------------------
+         
+         C->A : Connect                    C->B : Connect
+         C->A : PASV
+         A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
+                                           C->B : PORT A1,A2,A3,A4,a1,a2
+                                           B->C : 200 Okay
+         C->A : STOR                       C->B : RETR
+                    B->A : Connect to HOST-A, PORT-a
+
+                                Figure 3
+
+      The data connection shall be closed by the server under the
+      conditions described in the Section on Establishing Data
+      Connections.  If the data connection is to be closed following a
+      data transfer where closing the connection is not required to
+      indicate the end-of-file, the server must do so immediately.
+      Waiting until after a new transfer command is not permitted
+      because the user-process will have already tested the data
+      connection to see if it needs to do a "listen"; (remember that the
+      user must "listen" on a closed data port BEFORE sending the
+      transfer request).  To prevent a race condition here, the server
+      sends a reply (226) after closing the data connection (or if the
+      connection is left open, a "file transfer completed" reply (250)
+      and the user-PI should wait for one of these replies before
+      issuing a new transfer command).
+
+      Any time either the user or server see that the connection is
+      being closed by the other side, it should promptly read any
+      remaining data queued on the connection and issue the close on its
+      own side.
+
+   5.3.  COMMANDS
+
+      The commands are Telnet character strings transmitted over the
+      control connections as described in the Section on FTP Commands.
+      The command functions and semantics are described in the Section
+      on Access Control Commands, Transfer Parameter Commands, FTP
+      Service Commands, and Miscellaneous Commands.  The command syntax
+      is specified here.
+
+      The commands begin with a command code followed by an argument
+      field.  The command codes are four or fewer alphabetic characters.
+      Upper and lower case alphabetic characters are to be treated
+      identically.  Thus, any of the following may represent the
+      retrieve command:
+
+
+Postel & Reynolds                                              [Page 45]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+                  RETR    Retr    retr    ReTr    rETr
+
+      This also applies to any symbols representing parameter values,
+      such as A or a for ASCII TYPE.  The command codes and the argument
+      fields are separated by one or more spaces.
+
+      The argument field consists of a variable length character string
+      ending with the character sequence <CRLF> (Carriage Return, Line
+      Feed) for NVT-ASCII representation; for other negotiated languages
+      a different end of line character might be used.  It should be
+      noted that the server is to take no action until the end of line
+      code is received.
+
+      The syntax is specified below in NVT-ASCII.  All characters in the
+      argument field are ASCII characters including any ASCII
+      represented decimal integers.  Square brackets denote an optional
+      argument field.  If the option is not taken, the appropriate
+      default is implied.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 46]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      5.3.1.  FTP COMMANDS
+
+         The following are the FTP commands:
+
+            USER <SP> <username> <CRLF>
+            PASS <SP> <password> <CRLF>
+            ACCT <SP> <account-information> <CRLF>
+            CWD  <SP> <pathname> <CRLF>
+            CDUP <CRLF>
+            SMNT <SP> <pathname> <CRLF>
+            QUIT <CRLF>
+            REIN <CRLF>
+            PORT <SP> <host-port> <CRLF>
+            PASV <CRLF>
+            TYPE <SP> <type-code> <CRLF>
+            STRU <SP> <structure-code> <CRLF>
+            MODE <SP> <mode-code> <CRLF>
+            RETR <SP> <pathname> <CRLF>
+            STOR <SP> <pathname> <CRLF>
+            STOU <CRLF>
+            APPE <SP> <pathname> <CRLF>
+            ALLO <SP> <decimal-integer>
+                [<SP> R <SP> <decimal-integer>] <CRLF>
+            REST <SP> <marker> <CRLF>
+            RNFR <SP> <pathname> <CRLF>
+            RNTO <SP> <pathname> <CRLF>
+            ABOR <CRLF>
+            DELE <SP> <pathname> <CRLF>
+            RMD  <SP> <pathname> <CRLF>
+            MKD  <SP> <pathname> <CRLF>
+            PWD  <CRLF>
+            LIST [<SP> <pathname>] <CRLF>
+            NLST [<SP> <pathname>] <CRLF>
+            SITE <SP> <string> <CRLF>
+            SYST <CRLF>
+            STAT [<SP> <pathname>] <CRLF>
+            HELP [<SP> <string>] <CRLF>
+            NOOP <CRLF>
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 47]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      5.3.2.  FTP COMMAND ARGUMENTS
+
+         The syntax of the above argument fields (using BNF notation
+         where applicable) is:
+
+            <username> ::= <string>
+            <password> ::= <string>
+            <account-information> ::= <string>
+            <string> ::= <char> | <char><string>
+            <char> ::= any of the 128 ASCII characters except <CR> and
+            <LF>
+            <marker> ::= <pr-string>
+            <pr-string> ::= <pr-char> | <pr-char><pr-string>
+            <pr-char> ::= printable characters, any
+                          ASCII code 33 through 126
+            <byte-size> ::= <number>
+            <host-port> ::= <host-number>,<port-number>
+            <host-number> ::= <number>,<number>,<number>,<number>
+            <port-number> ::= <number>,<number>
+            <number> ::= any decimal integer 1 through 255
+            <form-code> ::= N | T | C
+            <type-code> ::= A [<sp> <form-code>]
+                          | E [<sp> <form-code>]
+                          | I
+                          | L <sp> <byte-size>
+            <structure-code> ::= F | R | P
+            <mode-code> ::= S | B | C
+            <pathname> ::= <string>
+            <decimal-integer> ::= any decimal integer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 48]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   5.4.  SEQUENCING OF COMMANDS AND REPLIES
+
+      The communication between the user and server is intended to be an
+      alternating dialogue.  As such, the user issues an FTP command and
+      the server responds with a prompt primary reply.  The user should
+      wait for this initial primary success or failure response before
+      sending further commands.
+
+      Certain commands require a second reply for which the user should
+      also wait.  These replies may, for example, report on the progress
+      or completion of file transfer or the closing of the data
+      connection.  They are secondary replies to file transfer commands.
+
+      One important group of informational replies is the connection
+      greetings.  Under normal circumstances, a server will send a 220
+      reply, "awaiting input", when the connection is completed.  The
+      user should wait for this greeting message before sending any
+      commands.  If the server is unable to accept input right away, a
+      120 "expected delay" reply should be sent immediately and a 220
+      reply when ready.  The user will then know not to hang up if there
+      is a delay.
+
+      Spontaneous Replies
+
+         Sometimes "the system" spontaneously has a message to be sent
+         to a user (usually all users).  For example, "System going down
+         in 15 minutes".  There is no provision in FTP for such
+         spontaneous information to be sent from the server to the user.
+         It is recommended that such information be queued in the
+         server-PI and delivered to the user-PI in the next reply
+         (possibly making it a multi-line reply).
+
+      The table below lists alternative success and failure replies for
+      each command.  These must be strictly adhered to; a server may
+      substitute text in the replies, but the meaning and action implied
+      by the code numbers and by the specific command reply sequence
+      cannot be altered.
+
+      Command-Reply Sequences
+
+         In this section, the command-reply sequence is presented.  Each
+         command is listed with its possible replies; command groups are
+         listed together.  Preliminary replies are listed first (with
+         their succeeding replies indented and under them), then
+         positive and negative completion, and finally intermediary
+
+
+
+
+Postel & Reynolds                                              [Page 49]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+         replies with the remaining commands from the sequence
+         following.  This listing forms the basis for the state
+         diagrams, which will be presented separately.
+
+            Connection Establishment
+               120
+                  220
+               220
+               421
+            Login
+               USER
+                  230
+                  530
+                  500, 501, 421
+                  331, 332
+               PASS
+                  230
+                  202
+                  530
+                  500, 501, 503, 421
+                  332
+               ACCT
+                  230
+                  202
+                  530
+                  500, 501, 503, 421
+               CWD
+                  250
+                  500, 501, 502, 421, 530, 550
+               CDUP
+                  200
+                  500, 501, 502, 421, 530, 550
+               SMNT
+                  202, 250
+                  500, 501, 502, 421, 530, 550
+            Logout
+               REIN
+                  120
+                     220
+                  220
+                  421
+                  500, 502
+               QUIT
+                  221
+                  500
+
+
+
+
+Postel & Reynolds                                              [Page 50]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+            Transfer parameters
+               PORT
+                  200
+                  500, 501, 421, 530
+               PASV
+                  227
+                  500, 501, 502, 421, 530
+               MODE
+                  200
+                  500, 501, 504, 421, 530
+               TYPE
+                  200
+                  500, 501, 504, 421, 530
+               STRU
+                  200
+                  500, 501, 504, 421, 530
+            File action commands
+               ALLO
+                  200
+                  202
+                  500, 501, 504, 421, 530
+               REST
+                  500, 501, 502, 421, 530
+                  350
+               STOR
+                  125, 150
+                     (110)
+                     226, 250
+                     425, 426, 451, 551, 552
+                  532, 450, 452, 553
+                  500, 501, 421, 530
+               STOU
+                  125, 150
+                     (110)
+                     226, 250
+                     425, 426, 451, 551, 552
+                  532, 450, 452, 553
+                  500, 501, 421, 530
+               RETR
+                  125, 150
+                     (110)
+                     226, 250
+                     425, 426, 451
+                  450, 550
+                  500, 501, 421, 530
+
+
+
+
+Postel & Reynolds                                              [Page 51]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+               LIST
+                  125, 150
+                     226, 250
+                     425, 426, 451
+                  450
+                  500, 501, 502, 421, 530
+               NLST
+                  125, 150
+                     226, 250
+                     425, 426, 451
+                  450
+                  500, 501, 502, 421, 530
+               APPE
+                  125, 150
+                     (110)
+                     226, 250
+                     425, 426, 451, 551, 552
+                  532, 450, 550, 452, 553
+                  500, 501, 502, 421, 530
+               RNFR
+                  450, 550
+                  500, 501, 502, 421, 530
+                  350
+               RNTO
+                  250
+                  532, 553
+                  500, 501, 502, 503, 421, 530
+               DELE
+                  250
+                  450, 550
+                  500, 501, 502, 421, 530
+               RMD
+                  250
+                  500, 501, 502, 421, 530, 550
+               MKD
+                  257
+                  500, 501, 502, 421, 530, 550
+               PWD
+                  257
+                  500, 501, 502, 421, 550
+               ABOR
+                  225, 226
+                  500, 501, 502, 421
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 52]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+            Informational commands
+               SYST
+                  215
+                  500, 501, 502, 421
+               STAT
+                  211, 212, 213
+                  450
+                  500, 501, 502, 421, 530
+               HELP
+                  211, 214
+                  500, 501, 502, 421
+            Miscellaneous commands
+               SITE
+                  200
+                  202
+                  500, 501, 530
+               NOOP
+                  200
+                  500 421
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 53]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+6.  STATE DIAGRAMS
+
+   Here we present state diagrams for a very simple minded FTP
+   implementation.  Only the first digit of the reply codes is used.
+   There is one state diagram for each group of FTP commands or command
+   sequences.
+
+   The command groupings were determined by constructing a model for
+   each command then collecting together the commands with structurally
+   identical models.
+
+   For each command or command sequence there are three possible
+   outcomes: success (S), failure (F), and error (E).  In the state
+   diagrams below we use the symbol B for "begin", and the symbol W for
+   "wait for reply".
+
+   We first present the diagram that represents the largest group of FTP
+   commands:
+
+      
+                               1,3    +---+
+                          ----------->| E |
+                         |            +---+
+                         |
+      +---+    cmd    +---+    2      +---+
+      | B |---------->| W |---------->| S |
+      +---+           +---+           +---+
+                         |
+                         |     4,5    +---+
+                          ----------->| F |
+                                      +---+
+      
+
+      This diagram models the commands:
+
+         ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV,
+         QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, and TYPE.
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 54]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   The other large group of commands is represented by a very similar
+   diagram:
+
+      
+                               3      +---+
+                          ----------->| E |
+                         |            +---+
+                         |
+      +---+    cmd    +---+    2      +---+
+      | B |---------->| W |---------->| S |
+      +---+       --->+---+           +---+
+                 |     | |
+                 |     | |     4,5    +---+
+                 |  1  |  ----------->| F |
+                  -----               +---+
+      
+
+      This diagram models the commands:
+
+         APPE, LIST, NLST, REIN, RETR, STOR, and STOU.
+
+   Note that this second model could also be used to represent the first
+   group of commands, the only difference being that in the first group
+   the 100 series replies are unexpected and therefore treated as error,
+   while the second group expects (some may require) 100 series replies.
+   Remember that at most, one 100 series reply is allowed per command.
+
+   The remaining diagrams model command sequences, perhaps the simplest
+   of these is the rename sequence:
+
+      
+      +---+   RNFR    +---+    1,2    +---+
+      | B |---------->| W |---------->| E |
+      +---+           +---+        -->+---+
+                       | |        |
+                3      | | 4,5    |
+         --------------  ------   |
+        |                      |  |   +---+
+        |               ------------->| S |
+        |              |   1,3 |  |   +---+
+        |             2|  --------
+        |              | |     |
+        V              | |     |
+      +---+   RNTO    +---+ 4,5 ----->+---+
+      |   |---------->| W |---------->| F |
+      +---+           +---+           +---+
+      
+
+
+Postel & Reynolds                                              [Page 55]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   The next diagram is a simple model of the Restart command:
+
+      
+      +---+   REST    +---+    1,2    +---+
+      | B |---------->| W |---------->| E |
+      +---+           +---+        -->+---+
+                       | |        |
+                3      | | 4,5    |
+         --------------  ------   |
+        |                      |  |   +---+
+        |               ------------->| S |
+        |              |   3   |  |   +---+
+        |             2|  --------
+        |              | |     |
+        V              | |     |
+      +---+   cmd     +---+ 4,5 ----->+---+
+      |   |---------->| W |---------->| F |
+      +---+        -->+---+           +---+
+                  |      |
+                  |  1   |
+                   ------
+      
+
+         Where "cmd" is APPE, STOR, or RETR.
+
+   We note that the above three models are similar.  The Restart differs
+   from the Rename two only in the treatment of 100 series replies at
+   the second stage, while the second group expects (some may require)
+   100 series replies.  Remember that at most, one 100 series reply is
+   allowed per command.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 56]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   The most complicated diagram is for the Login sequence:
+
+      
+                            1
+      +---+   USER    +---+------------->+---+
+      | B |---------->| W | 2       ---->| E |
+      +---+           +---+------  |  -->+---+
+                       | |       | | |
+                     3 | | 4,5   | | |
+         --------------   -----  | | |
+        |                      | | | |
+        |                      | | | |
+        |                 ---------  |
+        |               1|     | |   |
+        V                |     | |   |
+      +---+   PASS    +---+ 2  |  ------>+---+
+      |   |---------->| W |------------->| S |
+      +---+           +---+   ---------->+---+
+                       | |   | |     |
+                     3 | |4,5| |     |
+         --------------   --------   |
+        |                    | |  |  |
+        |                    | |  |  |
+        |                 -----------
+        |             1,3|   | |  |
+        V                |  2| |  |
+      +---+   ACCT    +---+--  |   ----->+---+
+      |   |---------->| W | 4,5 -------->| F |
+      +---+           +---+------------->+---+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 57]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   Finally, we present a generalized diagram that could be used to model
+   the command and reply interchange:
+
+      
+               ------------------------------------
+              |                                    |
+      Begin   |                                    |
+        |     V                                    |
+        |   +---+  cmd   +---+ 2         +---+     |
+         -->|   |------->|   |---------->|   |     |
+            |   |        | W |           | S |-----|
+         -->|   |     -->|   |-----      |   |     |
+        |   +---+    |   +---+ 4,5 |     +---+     |
+        |     |      |    | |      |               |
+        |     |      |   1| |3     |     +---+     |
+        |     |      |    | |      |     |   |     |
+        |     |       ----  |       ---->| F |-----
+        |     |             |            |   |
+        |     |             |            +---+
+         -------------------
+              |
+              |
+              V
+             End
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 58]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+7.  TYPICAL FTP SCENARIO
+
+   User at host U wanting to transfer files to/from host S:
+
+   In general, the user will communicate to the server via a mediating
+   user-FTP process.  The following may be a typical scenario.  The
+   user-FTP prompts are shown in parentheses, '---->' represents
+   commands from host U to host S, and '<----' represents replies from
+   host S to host U.
+
+      LOCAL COMMANDS BY USER              ACTION INVOLVED
+
+      ftp (host) multics<CR>         Connect to host S, port L,
+                                     establishing control connections.
+                                     <---- 220 Service ready <CRLF>.
+      username Doe <CR>              USER Doe<CRLF>---->
+                                     <---- 331 User name ok,
+                                               need password<CRLF>.
+      password mumble <CR>           PASS mumble<CRLF>---->
+                                     <---- 230 User logged in<CRLF>.
+      retrieve (local type) ASCII<CR>
+      (local pathname) test 1 <CR>   User-FTP opens local file in ASCII.
+      (for. pathname) test.pl1<CR>   RETR test.pl1<CRLF> ---->
+                                     <---- 150 File status okay;
+                                           about to open data
+                                           connection<CRLF>.
+                                     Server makes data connection
+                                     to port U.
+      
+                                     <---- 226 Closing data connection,
+                                         file transfer successful<CRLF>.
+      type Image<CR>                 TYPE I<CRLF> ---->
+                                     <---- 200 Command OK<CRLF>
+      store (local type) image<CR>
+      (local pathname) file dump<CR> User-FTP opens local file in Image.
+      (for.pathname) >udd>cn>fd<CR>  STOR >udd>cn>fd<CRLF> ---->
+                                     <---- 550 Access denied<CRLF>
+      terminate                      QUIT <CRLF> ---->
+                                     Server closes all
+                                     connections.
+
+8.  CONNECTION ESTABLISHMENT
+
+   The FTP control connection is established via TCP between the user
+   process port U and the server process port L.  This protocol is
+   assigned the service port 21 (25 octal), that is L=21.
+
+
+
+Postel & Reynolds                                              [Page 59]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+APPENDIX I -  PAGE STRUCTURE
+
+   The need for FTP to support page structure derives principally from
+   the  need to support efficient transmission of files between TOPS-20
+   systems, particularly the files used by NLS.
+
+   The file system of TOPS-20 is based on the concept of pages.  The
+   operating system is most efficient at manipulating files as pages.
+   The operating system provides an interface to the file system so that
+   many applications view files as sequential streams of characters.
+   However, a few applications use the underlying page structures
+   directly, and some of these create holey files.
+
+   A TOPS-20 disk file consists of four things: a pathname, a page
+   table, a (possibly empty) set of pages, and a set of attributes.
+
+   The pathname is specified in the RETR or STOR command.  It includes
+   the directory name, file name, file name extension, and generation
+   number.
+
+   The page table contains up to 2**18 entries.  Each entry may be
+   EMPTY, or may point to a page.  If it is not empty, there are also
+   some page-specific access bits; not all pages of a file need have the
+   same access protection.
+
+      A page is a contiguous set of 512 words of 36 bits each.
+
+   The attributes of the file, in the File Descriptor Block (FDB),
+   contain such things as creation time, write time, read time, writer's
+   byte-size, end-of-file pointer, count of reads and writes, backup
+   system tape numbers, etc.
+
+   Note that there is NO requirement that entries in the page table be
+   contiguous.  There may be empty page table slots between occupied
+   ones.  Also, the end of file pointer is simply a number.  There is no
+   requirement that it in fact point at the "last" datum in the file.
+   Ordinary sequential I/O calls in TOPS-20 will cause the end of file
+   pointer to be left after the last datum written, but other operations
+   may cause it not to be so, if a particular programming system so
+   requires.
+
+   In fact, in both of these special cases, "holey" files and
+   end-of-file pointers NOT at the end of the file, occur with NLS data
+   files.
+
+
+
+
+
+Postel & Reynolds                                              [Page 60]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   The TOPS-20 paged files can be sent with the FTP transfer parameters:
+   TYPE L 36, STRU P, and MODE S (in fact, any mode could be used).
+
+   Each page of information has a header.  Each header field, which is a
+   logical byte, is a TOPS-20 word, since the TYPE is L 36.
+
+   The header fields are:
+
+      Word 0: Header Length.
+
+         The header length is 5.
+
+      Word 1: Page Index.
+
+         If the data is a disk file page, this is the number of that
+         page in the file's page map.  Empty pages (holes) in the file
+         are simply not sent.  Note that a hole is NOT the same as a
+         page of zeros.
+
+      Word 2: Data Length.
+
+         The number of data words in this page, following the header.
+         Thus, the total length of the transmission unit is the Header
+         Length plus the Data Length.
+
+      Word 3: Page Type.
+
+         A code for what type of chunk this is.  A data page is type 3,
+         the FDB page is type 2.
+
+      Word 4: Page Access Control.
+
+         The access bits associated with the page in the file's page
+         map.  (This full word quantity is put into AC2 of an SPACS by
+         the program reading from net to disk.)
+
+   After the header are Data Length data words.  Data Length is
+   currently either 512 for a data page or 31 for an FDB.  Trailing
+   zeros in a disk file page may be discarded, making Data Length less
+   than 512 in that case.
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 61]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+APPENDIX II -  DIRECTORY COMMANDS
+
+   Since UNIX has a tree-like directory structure in which directories
+   are as easy to manipulate as ordinary files, it is useful to expand
+   the FTP servers on these machines to include commands which deal with
+   the creation of directories.  Since there are other hosts on the
+   ARPA-Internet which have tree-like directories (including TOPS-20 and
+   Multics), these commands are as general as possible.
+
+      Four directory commands have been added to FTP:
+
+         MKD pathname
+
+            Make a directory with the name "pathname".
+
+         RMD pathname
+
+            Remove the directory with the name "pathname".
+
+         PWD
+
+            Print the current working directory name.
+
+         CDUP
+
+            Change to the parent of the current working directory.
+
+   The  "pathname"  argument should be created (removed) as a
+   subdirectory of the current working directory, unless the "pathname"
+   string contains sufficient information to specify otherwise to the
+   server, e.g., "pathname" is an absolute pathname (in UNIX and
+   Multics), or pathname is something like "<abso.lute.path>" to
+   TOPS-20.
+
+   REPLY CODES
+
+      The CDUP command is a special case of CWD, and is included to
+      simplify the implementation of programs for transferring directory
+      trees between operating systems having different syntaxes for
+      naming the parent directory.  The reply codes for CDUP be
+      identical to the reply codes of CWD.
+
+      The reply codes for RMD be identical to the reply codes for its
+      file analogue, DELE.
+
+      The reply codes for MKD, however, are a bit more complicated.  A
+      freshly created directory will probably be the object of a future
+
+
+Postel & Reynolds                                              [Page 62]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      CWD command.  Unfortunately, the argument to MKD may not always be
+      a suitable argument for CWD.  This is the case, for example, when
+      a TOPS-20 subdirectory is created by giving just the subdirectory
+      name.  That is, with a TOPS-20 server FTP, the command sequence
+
+         MKD MYDIR
+         CWD MYDIR
+
+      will fail.  The new directory may only be referred to by its
+      "absolute" name; e.g., if the MKD command above were issued while
+      connected to the directory <DFRANKLIN>, the new subdirectory
+      could only be referred to by the name <DFRANKLIN.MYDIR>.
+
+      Even on UNIX and Multics, however, the argument given to MKD may
+      not be suitable.  If it is a "relative" pathname (i.e., a pathname
+      which is interpreted relative to the current directory), the user
+      would need to be in the same current directory in order to reach
+      the subdirectory.  Depending on the application, this may be
+      inconvenient.  It is not very robust in any case.
+
+      To solve these problems, upon successful completion of an MKD
+      command, the server should return a line of the form:
+
+         257<space>"<directory-name>"<space><commentary>
+
+      That is, the server will tell the user what string to use when
+      referring to the created  directory.  The directory name can
+      contain any character; embedded double-quotes should be escaped by
+      double-quotes (the "quote-doubling" convention).
+
+      For example, a user connects to the directory /usr/dm, and creates
+      a subdirectory, named pathname:
+
+         CWD /usr/dm
+         200 directory changed to /usr/dm
+         MKD pathname
+         257 "/usr/dm/pathname" directory created
+
+      An example with an embedded double quote:
+
+         MKD foo"bar
+         257 "/usr/dm/foo""bar" directory created
+         CWD /usr/dm/foo"bar
+         200 directory changed to /usr/dm/foo"bar
+
+
+
+
+
+Postel & Reynolds                                              [Page 63]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      The prior existence of a subdirectory with the same name is an
+      error, and the server must return an "access denied" error reply
+      in that case.
+
+         CWD /usr/dm
+         200 directory changed to /usr/dm
+         MKD pathname
+         521-"/usr/dm/pathname" directory already exists;
+         521 taking no action.
+
+      The failure replies for MKD are analogous to its file  creating
+      cousin, STOR.  Also, an "access denied" return is given if a file
+      name with the same name as the subdirectory will conflict with the
+      creation of the subdirectory (this is a problem on UNIX, but
+      shouldn't be one on TOPS-20).
+
+      Essentially because the PWD command returns the same type of
+      information as the successful MKD command, the successful PWD
+      command uses the 257 reply code as well.
+
+   SUBTLETIES
+
+      Because these commands will be most useful in transferring
+      subtrees from one machine to another, carefully observe that the
+      argument to MKD is to be interpreted as a sub-directory of  the
+      current working directory, unless it contains enough information
+      for the destination host to tell otherwise.  A hypothetical
+      example of its use in the TOPS-20 world:
+
+         CWD <some.where>
+         200 Working directory changed
+         MKD overrainbow
+         257 "<some.where.overrainbow>" directory created
+         CWD overrainbow
+         431 No such directory
+         CWD <some.where.overrainbow>
+         200 Working directory changed
+
+         CWD <some.where>
+         200 Working directory changed to <some.where>
+         MKD <unambiguous>
+         257 "<unambiguous>" directory created
+         CWD <unambiguous>
+
+      Note that the first example results in a subdirectory of the
+      connected directory.  In contrast, the argument in the second
+      example contains enough information for TOPS-20 to tell that  the
+
+
+Postel & Reynolds                                              [Page 64]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+      <unambiguous> directory is a top-level directory.  Note also that
+      in the first example the user "violated" the protocol by
+      attempting to access the freshly created directory with a name
+      other than the one returned by TOPS-20.  Problems could have
+      resulted in this case had there been an <overrainbow> directory;
+      this is an ambiguity inherent in some TOPS-20 implementations.
+      Similar considerations apply to the RMD command.  The point is
+      this: except where to do so would violate a host's conventions for
+      denoting relative versus absolute pathnames, the host should treat
+      the operands of the MKD and RMD commands as subdirectories.  The
+      257 reply to the MKD command must always contain the absolute
+      pathname of the created directory.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 65]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+APPENDIX III - RFCs on FTP
+
+   Bhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823),
+   MIT-Project MAC, 16 April 1971.
+
+   Harslem, Eric, and John Heafner, "Comments on RFC 114 (A File
+   Transfer Protocol)", RFC 141 (NIC 6726), RAND, 29 April 1971.
+
+   Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172
+   (NIC 6794), MIT-Project MAC, 23 June 1971.
+
+   Braden, Bob, "Comments on DTP and FTP Proposals", RFC 238 (NIC 7663),
+   UCLA/CCN, 29 September 1971.
+
+   Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 265
+   (NIC 7813), MIT-Project MAC, 17 November 1971.
+
+   McKenzie, Alex, "A Suggested Addition to File Transfer Protocol",
+   RFC 281 (NIC 8163), BBN, 8 December 1971.
+
+   Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File
+   Transfer Protocol", RFC 294 (NIC 8304), MIT-Project MAC,
+   25 January 1972.
+
+   Bhushan, Abhay, "The File Transfer Protocol", RFC 354 (NIC 10596),
+   MIT-Project MAC, 8 July 1972.
+
+   Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC 354)",
+   RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972.
+
+   Hicks, Greg, "User FTP Documentation", RFC 412 (NIC 12404), Utah,
+   27 November 1972.
+
+   Bhushan, Abhay, "File Transfer Protocol (FTP) Status and Further
+   Comments", RFC 414 (NIC 12406), MIT-Project MAC, 20 November 1972.
+
+   Braden, Bob, "Comments on File Transfer Protocol", RFC 430
+   (NIC 13299), UCLA/CCN, 7 February 1973.
+
+   Thomas, Bob, and Bob Clements, "FTP Server-Server Interaction",
+   RFC 438 (NIC 13770), BBN, 15 January 1973.
+
+   Braden, Bob, "Print Files in FTP", RFC 448 (NIC 13299), UCLA/CCN,
+   27 February 1973.
+
+   McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14333), BBN,
+   16 February 1973.
+
+
+Postel & Reynolds                                              [Page 66]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   Bressler, Bob, and Bob Thomas, "Mail Retrieval via FTP", RFC 458
+   (NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973.
+
+   Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17759), BBN,
+   12 July 1973.
+
+   Krilanovich, Mark, and George Gregg, "Comments on the File Transfer
+   Protocol", RFC 607 (NIC 21255), UCSB, 7 January 1974.
+
+   Pogran, Ken, and Nancy Neigus, "Response to RFC 607 - Comments on the
+   File Transfer Protocol", RFC 614 (NIC 21530), BBN, 28 January 1974.
+
+   Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White,
+   "Comments on the File Transfer Protocol", RFC 624 (NIC 22054), UCSB,
+   Ames Research Center, SRI-ARC, 28 February 1974.
+
+   Bhushan, Abhay, "FTP Comments and Response to RFC 430", RFC 463
+   (NIC 14573), MIT-DMCG, 21 February 1973.
+
+   Braden, Bob, "FTP Data Compression", RFC 468 (NIC 14742), UCLA/CCN,
+   8 March 1973.
+
+   Bhushan, Abhay, "FTP and Network Mail System", RFC 475 (NIC 14919),
+   MIT-DMCG, 6 March 1973.
+
+   Bressler, Bob, and Bob Thomas "FTP Server-Server Interaction - II",
+   RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973.
+
+   White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948),
+   SRI-ARC, 8 March 1973.
+
+   White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949),
+   SRI-ARC, 8 March 1973.
+
+   Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506
+   (NIC 16157), MIT-Multics, 26 June 1973.
+
+   Day, John, "Memo to FTP Group (Proposal for File Access Protocol)",
+   RFC 520 (NIC 16819), Illinois, 25 June 1973.
+
+   Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532
+   (NIC 17451), UCSD-CC, 22 June 1973.
+
+   Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN,
+   15 November 1973.
+
+
+
+
+Postel & Reynolds                                              [Page 67]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+   McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation -
+   Schedule Change", RFC 593 (NIC 20615), BBN and MITRE,
+   29 November 1973.
+
+   Sussman, Julie, "FTP Error Code Usage for More Reliable Mail
+   Service", RFC 630 (NIC 30237), BBN, 10 April 1974.
+
+   Postel, Jon, "Revised FTP Reply Codes", RFC 640 (NIC 30843),
+   UCLA/NMC, 5 June 1974.
+
+   Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481),
+   SU-AI, 10 May 1975.
+
+   Harvey, Brian, "One More Try on the FTP", RFC 691 (NIC 32700), SU-AI,
+   28 May 1975.
+
+   Lieb, J., "CWD Command of FTP", RFC 697 (NIC 32963), 14 July 1975.
+
+   Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL,
+   31 October 1977.
+
+   Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758),
+   SRI-KL, 30 December 1977.
+
+   Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT,
+   10 December 1978.
+
+   Postel, Jon, "File Transfer Protocol Specification", RFC 765, ISI,
+   June 1980.
+
+   Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP
+   Commands", RFC 776, BBN, December 1980.
+
+   Padlipsky, Michael, "FTP Unique-Named Store Command", RFC 949, MITRE,
+   July 1985.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 68]
+
+
+                                                                        
+RFC 959                                                     October 1985
+File Transfer Protocol
+
+
+REFERENCES
+
+   [1]  Feinler, Elizabeth, "Internet Protocol Transition Workbook",
+        Network Information Center, SRI International, March 1982.
+
+   [2]  Postel, Jon, "Transmission Control Protocol - DARPA Internet
+        Program Protocol Specification", RFC 793, DARPA, September 1981.
+
+   [3]  Postel, Jon, and Joyce Reynolds, "Telnet Protocol
+        Specification", RFC 854, ISI, May 1983.
+
+   [4]  Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC 943,
+        ISI, April 1985.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 69]
+