You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@labs.apache.org by fi...@apache.org on 2007/11/03 03:23:16 UTC
svn commit: r591538 - in /labs/webarch/trunk/http/draft-fielding-http:
p1-messaging.html p1-messaging.xml
Author: fielding
Date: Fri Nov 2 19:23:16 2007
New Revision: 591538
URL: http://svn.apache.org/viewvc?rev=591538&view=rev
Log:
Resolve [LABS-49]: [i47] inconsistency in date format explanation
Modified:
labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html
labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml
Modified: labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html?rev=591538&r1=591537&r2=591538&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html Fri Nov 2 19:23:16 2007
@@ -581,7 +581,7 @@
</ul>
<h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1>
<p id="rfc.section.1.p.1">This document will define aspects of HTTP related to overall network operation, message framing, interaction with transport
- protocols, and URI schemes. Right now it only includes the extracted relevant sections of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[30]</cite></a> and <a href="#RFC2617" id="rfc.xref.RFC2617.1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[31]</cite></a>.
+ protocols, and URI schemes. Right now it only includes the extracted relevant sections of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[29]</cite></a> and <a href="#RFC2617" id="rfc.xref.RFC2617.1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[30]</cite></a>.
</p>
<h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.purpose" href="#intro.purpose">Purpose</a></h2>
<p id="rfc.section.1.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information
@@ -596,15 +596,15 @@
HTTP/1.0 in order to ensure reliable implementation of its features.
</p>
<p id="rfc.section.1.1.p.3">Practical information systems require more functionality than simple retrieval, including search, front-end update, and annotation.
- HTTP allows an open-ended set of methods and headers that indicate the purpose of a request <a href="#RFC2324" id="rfc.xref.RFC2324.1"><cite title="Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)">[32]</cite></a>. It builds on the discipline of reference provided by the Uniform Resource Identifier (URI) <a href="#RFC1630" id="rfc.xref.RFC1630.1"><cite title="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">[2]</cite></a>, as a location (URL) <a href="#RFC1738" id="rfc.xref.RFC1738.1"><cite title="Uniform Resource Locators (URL)">[3]</cite></a> or name (URN) <a href="#RFC1737" id="rfc.xref.RFC1737.1"><cite title="Functional Requirements for Uniform Resource Names">[17]</cite></a>, for indicating the resource to which a method is to be applied. Messages are passed in a format similar to that used by
+ HTTP allows an open-ended set of methods and headers that indicate the purpose of a request <a href="#RFC2324" id="rfc.xref.RFC2324.1"><cite title="Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)">[31]</cite></a>. It builds on the discipline of reference provided by the Uniform Resource Identifier (URI) <a href="#RFC1630" id="rfc.xref.RFC1630.1"><cite title="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">[2]</cite></a>, as a location (URL) <a href="#RFC1738" id="rfc.xref.RFC1738.1"><cite title="Uniform Resource Locators (URL)">[3]</cite></a> or name (URN) <a href="#RFC1737" id="rfc.xref.RFC1737.1"><cite title="Functional Requirements for Uniform Resource Names">[16]</cite></a>, 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 <a href="#RFC822" id="rfc.xref.RFC822.1"><cite title="Standard for the format of ARPA Internet text messages">[7]</cite></a> as defined by the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[5]</cite></a>.
</p>
<p id="rfc.section.1.1.p.4">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 <a href="#RFC821" id="rfc.xref.RFC821.1"><cite title="Simple Mail Transfer Protocol">[13]</cite></a>, NNTP <a href="#RFC977" id="rfc.xref.RFC977.1"><cite title="Network News Transfer Protocol">[11]</cite></a>, FTP <a href="#RFC959" id="rfc.xref.RFC959.1"><cite title="File Transfer Protocol">[15]</cite></a>, Gopher <a href="#RFC1436" id="rfc.xref.RFC1436.1"><cite title="The Internet Gopher Protocol (a distributed document search and retrieval protocol)">[1]</cite></a>, and WAIS <a href="#WAIS" id="rfc.xref.WAIS.1"><cite title="WAIS Interface Protocol Prototype Functional Specification (v1.5)">[8]</cite></a> protocols. In this way, HTTP allows basic hypermedia access to resources available from diverse applications.
+ including those supported by the SMTP <a href="#RFC821" id="rfc.xref.RFC821.1"><cite title="Simple Mail Transfer Protocol">[12]</cite></a>, NNTP <a href="#RFC977" id="rfc.xref.RFC977.1"><cite title="Network News Transfer Protocol">[10]</cite></a>, FTP <a href="#RFC959" id="rfc.xref.RFC959.1"><cite title="File Transfer Protocol">[14]</cite></a>, Gopher <a href="#RFC1436" id="rfc.xref.RFC1436.1"><cite title="The Internet Gopher Protocol (a distributed document search and retrieval protocol)">[1]</cite></a>, and WAIS <a href="#WAIS" id="rfc.xref.WAIS.1"><cite title="WAIS Interface Protocol Prototype Functional Specification (v1.5)">[8]</cite></a> protocols. In this way, HTTP allows basic hypermedia access to resources available from diverse applications.
</p>
<h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
<p id="rfc.section.1.2.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
- in this document are to be interpreted as described in RFC 2119 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[26]</cite></a>.
+ in this document are to be interpreted as described in RFC 2119 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[25]</cite></a>.
</p>
<p id="rfc.section.1.2.p.2">An implementation is not compliant if it fails to satisfy one or more of the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level requirements for the protocols it implements. An implementation that satisfies all the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level and all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the <em class="bcp14">MUST</em> level requirements but not all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "conditionally compliant."
</p>
@@ -799,7 +799,7 @@
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.
</p>
- <p id="rfc.section.1.4.p.11">HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 <a href="#RFC1700" id="rfc.xref.RFC1700.1"><cite title="Assigned Numbers">[16]</cite></a>, but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet,
+ <p id="rfc.section.1.4.p.11">HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 <a href="#RFC1700" id="rfc.xref.RFC1700.1"><cite title="Assigned Numbers">[15]</cite></a>, 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.
@@ -882,7 +882,7 @@
</dl>
<h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="basic.rules" href="#basic.rules">Basic Rules</a></h2>
<p id="rfc.section.2.2.p.1">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 <a href="#USASCII" id="rfc.xref.USASCII.1"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[18]</cite></a>.
+ set is defined by ANSI X3.4-1986 <a href="#USASCII" id="rfc.xref.USASCII.1"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[17]</cite></a>.
</p>
<div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span> OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
@@ -906,7 +906,7 @@
</p>
<div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.14"></span> LWS = [CRLF] 1*( SP | HT )
</pre><p id="rfc.section.2.2.p.7">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 <em class="bcp14">MAY</em> contain characters from character sets other than ISO-8859-1 <a href="#ISO-8859" id="rfc.xref.ISO-8859.1"><cite title="Information technology - 8-bit single byte coded graphic - character sets">[19]</cite></a> only when encoded according to the rules of RFC 2047 <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[12]</cite></a>.
+ parser. Words of *TEXT <em class="bcp14">MAY</em> contain characters from character sets other than ISO-8859-1 <a href="#ISO-8859" id="rfc.xref.ISO-8859.1"><cite title="Information technology - 8-bit single byte coded graphic - character sets">[18]</cite></a> only when encoded according to the rules of RFC 2047 <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[11]</cite></a>.
</p>
<div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.15"></span> TEXT = <any OCTET except CTLs,
but including LWS>
@@ -943,7 +943,7 @@
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. See RFC 2145 <a href="#RFC2145" id="rfc.xref.RFC2145.1"><cite title="Use and Interpretation of HTTP Version Numbers">[27]</cite></a> for a fuller explanation.
+ of a message within the protocol is changed. See RFC 2145 <a href="#RFC2145" id="rfc.xref.RFC2145.1"><cite title="Use and Interpretation of HTTP Version Numbers">[26]</cite></a> for a fuller explanation.
</p>
<p id="rfc.section.3.1.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p>
<div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.24"></span> HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
@@ -952,14 +952,14 @@
</p>
<p id="rfc.section.3.1.p.5">An application that sends a request or response message that includes HTTP-Version of "HTTP/1.1" <em class="bcp14">MUST</em> be at least conditionally compliant with this specification. Applications that are at least conditionally compliant with this
specification <em class="bcp14">SHOULD</em> use an HTTP-Version of "HTTP/1.1" in their messages, and <em class="bcp14">MUST</em> do so for any message that is not compatible with HTTP/1.0. For more details on when to send specific HTTP-Version values,
- see RFC 2145 <a href="#RFC2145" id="rfc.xref.RFC2145.2"><cite title="Use and Interpretation of HTTP Version Numbers">[27]</cite></a>.
+ see RFC 2145 <a href="#RFC2145" id="rfc.xref.RFC2145.2"><cite title="Use and Interpretation of HTTP Version Numbers">[26]</cite></a>.
</p>
<p id="rfc.section.3.1.p.6">The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant.</p>
<p id="rfc.section.3.1.p.7">Proxy and gateway applications need to 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 <em class="bcp14">MUST NOT</em> send a message with a version indicator which is greater than its actual version. If a higher version request is received,
the proxy/gateway <em class="bcp14">MUST</em> either downgrade the request version, or respond with an error, or switch to tunnel behavior.
</p>
- <p id="rfc.section.3.1.p.8">Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[25]</cite></a>, caching proxies MUST, gateways <em class="bcp14">MAY</em>, and tunnels <em class="bcp14">MUST NOT</em> upgrade the request to the highest version they support. The proxy/gateway's response to that request <em class="bcp14">MUST</em> be in the same major version as the request.
+ <p id="rfc.section.3.1.p.8">Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[24]</cite></a>, caching proxies MUST, gateways <em class="bcp14">MAY</em>, and tunnels <em class="bcp14">MUST NOT</em> upgrade the request to the highest version they support. The proxy/gateway's response to that request <em class="bcp14">MUST</em> be in the same major version as the request.
</p>
<p id="rfc.section.3.1.p.9"> </p>
<dl class="empty">
@@ -967,13 +967,13 @@
</dd>
</dl>
<h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>
- <p id="rfc.section.3.2.p.1">URIs have been known by many names: WWW addresses, Universal Document Identifiers, Universal Resource Identifiers <a href="#RFC1630" id="rfc.xref.RFC1630.2"><cite title="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">[2]</cite></a>, and finally the combination of Uniform Resource Locators (URL) <a href="#RFC1738" id="rfc.xref.RFC1738.2"><cite title="Uniform Resource Locators (URL)">[3]</cite></a> and Names (URN) <a href="#RFC1737" id="rfc.xref.RFC1737.2"><cite title="Functional Requirements for Uniform Resource Names">[17]</cite></a>. As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify--via name, location,
+ <p id="rfc.section.3.2.p.1">URIs have been known by many names: WWW addresses, Universal Document Identifiers, Universal Resource Identifiers <a href="#RFC1630" id="rfc.xref.RFC1630.2"><cite title="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">[2]</cite></a>, and finally the combination of Uniform Resource Locators (URL) <a href="#RFC1738" id="rfc.xref.RFC1738.2"><cite title="Uniform Resource Locators (URL)">[3]</cite></a> and Names (URN) <a href="#RFC1737" id="rfc.xref.RFC1737.2"><cite title="Functional Requirements for Uniform Resource Names">[16]</cite></a>. As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify--via name, location,
or any other characteristic--a resource.
</p>
<h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="general.syntax" href="#general.syntax">General Syntax</a></h3>
<p id="rfc.section.3.2.1.p.1">URIs in HTTP can be represented in absolute form or relative to some known base URI <a href="#RFC1808" id="rfc.xref.RFC1808.1"><cite title="Relative Uniform Resource Locators">[9]</cite></a>, 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. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers
- (URI): Generic Syntax and Semantics," RFC 2396 <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[29]</cite></a> (which replaces RFCs 1738 <a href="#RFC1738" id="rfc.xref.RFC1738.3"><cite title="Uniform Resource Locators (URL)">[3]</cite></a> and RFC 1808 <a href="#RFC1808" id="rfc.xref.RFC1808.2"><cite title="Relative Uniform Resource Locators">[9]</cite></a>). This specification adopts the definitions of "URI-reference", "absoluteURI", "relativeURI", "port", "host","abs_path",
+ (URI): Generic Syntax and Semantics," RFC 2396 <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[28]</cite></a> (which replaces RFCs 1738 <a href="#RFC1738" id="rfc.xref.RFC1738.3"><cite title="Uniform Resource Locators (URL)">[3]</cite></a> and RFC 1808 <a href="#RFC1808" id="rfc.xref.RFC1808.2"><cite title="Relative Uniform Resource Locators">[9]</cite></a>). This specification adopts the definitions of "URI-reference", "absoluteURI", "relativeURI", "port", "host","abs_path",
"rel_path", and "authority" from that specification.
</p>
<p id="rfc.section.3.2.1.p.2">The HTTP protocol does not place any a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see [Part 2]).
@@ -990,7 +990,7 @@
</p>
<div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.25"></span>http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
</pre><p id="rfc.section.3.2.2.p.3">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 (<a href="#request-uri" title="Request-URI">Section 5.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see RFC 1900 <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[20]</cite></a>). If the abs_path is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a Request-URI for a resource (<a href="#request-uri" title="Request-URI">Section 5.1.2</a>). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
+ listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (<a href="#request-uri" title="Request-URI">Section 5.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see RFC 1900 <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[19]</cite></a>). If the abs_path is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a Request-URI for a resource (<a href="#request-uri" title="Request-URI">Section 5.1.2</a>). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
</p>
<h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="uri.comparison" href="#uri.comparison">URI Comparison</a></h3>
<p id="rfc.section.3.2.3.p.1">When comparing two URIs to decide if they match or not, a client <em class="bcp14">SHOULD</em> use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions:
@@ -1003,7 +1003,7 @@
</li>
<li>An empty abs_path is equivalent to an abs_path of "/".</li>
</ul>
- <p id="rfc.section.3.2.3.p.2">Characters other than those in the "reserved" set (see RFC 2396 <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[29]</cite></a>) are equivalent to their ""%" HEX HEX" encoding.
+ <p id="rfc.section.3.2.3.p.2">Characters other than those in the "reserved" set (see RFC 2396 <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[28]</cite></a>) are equivalent to their ""%" HEX HEX" encoding.
</p>
<p id="rfc.section.3.2.3.p.3">For example, the following three URIs are equivalent:</p>
<div id="rfc.figure.u.15"></div><pre class="text"> http://abc.com:80/~smith/home.html
@@ -1013,9 +1013,10 @@
<h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> <a id="full.date" href="#full.date">Full Date</a></h3>
<p id="rfc.section.3.3.1.p.1">HTTP applications have historically allowed three different formats for the representation of date/time stamps:</p>
<div id="rfc.figure.u.16"></div><pre class="text"> 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
+ Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
-</pre><p id="rfc.section.3.3.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[6]</cite></a> (an update to RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.3"><cite title="Standard for the format of ARPA Internet text messages">[7]</cite></a>). The second format is in common use, but is based on the obsolete RFC 850 <a href="#RFC1036" id="rfc.xref.RFC1036.1"><cite title="Standard for interchange of USENET messages">[10]</cite></a> date format and lacks a four-digit year. HTTP/1.1 clients and servers that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Ap
plications">Appendix B</a> for further information.
+</pre><p id="rfc.section.3.3.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[6]</cite></a> (an update to RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.3"><cite title="Standard for the format of ARPA Internet text messages">[7]</cite></a>). The other formats are described here only for compatibility with obsolete implementations. HTTP/1.1 clients and servers
+ that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix B</a> for further information.
</p>
<dl class="empty">
<dd> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications,
@@ -1316,7 +1317,7 @@
</pre><p id="rfc.section.5.1.2.p.11">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original
URI, it <em class="bcp14">MUST</em> be given as "/" (the server root).
</p>
- <p id="rfc.section.5.1.2.p.12">The Request-URI is transmitted in the format specified in <a href="#general.syntax" title="General Syntax">Section 3.2.1</a>. If the Request-URI is encoded using the "% HEX HEX" encoding <a href="#RFC2396" id="rfc.xref.RFC2396.3"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[29]</cite></a>, the origin server <em class="bcp14">MUST</em> decode the Request-URI in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid Request-URIs with an appropriate status code.
+ <p id="rfc.section.5.1.2.p.12">The Request-URI is transmitted in the format specified in <a href="#general.syntax" title="General Syntax">Section 3.2.1</a>. If the Request-URI is encoded using the "% HEX HEX" encoding <a href="#RFC2396" id="rfc.xref.RFC2396.3"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[28]</cite></a>, the origin server <em class="bcp14">MUST</em> decode the Request-URI in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid Request-URIs with an appropriate status code.
</p>
<p id="rfc.section.5.1.2.p.13">A transparent proxy <em class="bcp14">MUST NOT</em> rewrite the "abs_path" part of the received Request-URI when forwarding it to the next inbound server, except as noted above
to replace a null abs_path with "/".
@@ -1385,7 +1386,7 @@
<p id="rfc.section.7.1.1.p.1">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 require a client
to make multiple requests of the same server in a short amount of time. Analysis of these performance problems and results
- from a prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[21]</cite></a> <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[24]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 (RFC 2068) implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[28]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[22]</cite></a>.
+ from a prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[20]</cite></a> <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[23]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 (RFC 2068) implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[27]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[21]</cite></a>.
</p>
<p id="rfc.section.7.1.1.p.2">Persistent HTTP connections have a number of advantages: </p>
<ul>
@@ -1442,7 +1443,7 @@
<p id="rfc.section.7.1.3.p.2">The proxy server <em class="bcp14">MUST</em> 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.
</p>
- <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[25]</cite></a> for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients).
+ <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[24]</cite></a> for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients).
</p>
<h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
<p id="rfc.section.7.1.4.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers
@@ -1627,7 +1628,7 @@
</li>
</ol>
<p id="rfc.section.8.3.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient or gatewayed via a protocol which requires
- a Date. An HTTP implementation without a clock <em class="bcp14">MUST NOT</em> cache responses without revalidating them on every use. An HTTP cache, especially a shared cache, <em class="bcp14">SHOULD</em> use a mechanism, such as NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[23]</cite></a>, to synchronize its clock with a reliable external standard.
+ a Date. An HTTP implementation without a clock <em class="bcp14">MUST NOT</em> cache responses without revalidating them on every use. An HTTP cache, especially a shared cache, <em class="bcp14">SHOULD</em> use a mechanism, such as NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[22]</cite></a>, to synchronize its clock with a reliable external standard.
</p>
<p id="rfc.section.8.3.p.7">Clients <em class="bcp14">SHOULD</em> 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 client without a clock <em class="bcp14">MUST NOT</em> send a Date header field in a request.
@@ -1850,7 +1851,7 @@
<p id="rfc.section.9.4.p.3">If HTTP clients cache the results of host name lookups in order to achieve a performance improvement, they <em class="bcp14">MUST</em> observe the TTL information reported by DNS.
</p>
<p id="rfc.section.9.4.p.4">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 <a href="#RFC1900" id="rfc.xref.RFC1900.2"><cite title="Renumbering Needs Work">[20]</cite></a>, the possibility of this form of attack will grow. Observing this requirement thus reduces this potential security vulnerability.
+ network renumbering is expected to become increasingly common <a href="#RFC1900" id="rfc.xref.RFC1900.2"><cite title="Renumbering Needs Work">[19]</cite></a>, the possibility of this form of attack will grow. Observing this requirement thus reduces this potential security vulnerability.
</p>
<p id="rfc.section.9.4.p.5">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.
@@ -1967,51 +1968,46 @@
</td>
</tr>
<tr>
- <td class="reference"><b id="RFC1036">[10]</b></td>
- <td class="top">Horton, M. and R. Adams, â<a href="http://tools.ietf.org/html/rfc1036">Standard for interchange of USENET messages</a>â, RFC 1036, December 1987.
- </td>
- </tr>
- <tr>
- <td class="reference"><b id="RFC977">[11]</b></td>
+ <td class="reference"><b id="RFC977">[10]</b></td>
<td class="top">Kantor, B. and P. Lapsley, â<a href="http://tools.ietf.org/html/rfc977">Network News Transfer Protocol</a>â, RFC 977, February 1986.
</td>
</tr>
<tr>
- <td class="reference"><b id="RFC2047">[12]</b></td>
+ <td class="reference"><b id="RFC2047">[11]</b></td>
<td class="top"><a title="University of Tennessee">Moore, K.</a>, â<a href="http://tools.ietf.org/html/rfc2047">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</a>â, RFC 2047, November 1996.
</td>
</tr>
<tr>
- <td class="reference"><b id="RFC821">[13]</b></td>
+ <td class="reference"><b id="RFC821">[12]</b></td>
<td class="top">Postel, J.B., â<a href="http://tools.ietf.org/html/rfc821">Simple Mail Transfer Protocol</a>â, STD 10, RFC 821, August 1982.
</td>
</tr>
<tr>
- <td class="reference"><b id="RFC4288">[14]</b></td>
+ <td class="reference"><b id="RFC4288">[13]</b></td>
<td class="top"><a title="Sun Microsystems">Freed, N.</a> and <a>J. Klensin</a>, â<a href="http://tools.ietf.org/html/rfc4288">Media Type Specifications and Registration Procedures</a>â, BCP 13, RFC 4288, December 2005.
</td>
</tr>
<tr>
- <td class="reference"><b id="RFC959">[15]</b></td>
+ <td class="reference"><b id="RFC959">[14]</b></td>
<td class="top">Postel, J. and J. Reynolds, â<a href="http://tools.ietf.org/html/rfc959">File Transfer Protocol</a>â, STD 9, RFC 959, October 1985.
</td>
</tr>
<tr>
- <td class="reference"><b id="RFC1700">[16]</b></td>
+ <td class="reference"><b id="RFC1700">[15]</b></td>
<td class="top"><a title="USC/Information Sciences Institute">Reynolds, J.</a> and <a title="USC/Information Sciences Institute">J. Postel</a>, â<a href="http://tools.ietf.org/html/rfc1700">Assigned Numbers</a>â, STD 2, RFC 1700, October 1994.
</td>
</tr>
<tr>
- <td class="reference"><b id="RFC1737">[17]</b></td>
+ <td class="reference"><b id="RFC1737">[16]</b></td>
<td class="top"><a title="Xerox Palo Alto Research Center">Masinter, L.</a> and <a title="MIT Laboratory for Computer Science">K. Sollins</a>, â<a href="http://tools.ietf.org/html/rfc1737">Functional Requirements for Uniform Resource Names</a>â, RFC 1737, December 1994.
</td>
</tr>
<tr>
- <td class="reference"><b id="USASCII">[18]</b></td>
+ <td class="reference"><b id="USASCII">[17]</b></td>
<td class="top">American National Standards Institute, âCoded Character Set -- 7-bit American Standard Code for Information Interchangeâ, ANSI X3.4, 1986.</td>
</tr>
<tr>
- <td class="reference"><b id="ISO-8859">[19]</b></td>
+ <td class="reference"><b id="ISO-8859">[18]</b></td>
<td class="top">International Organization for Standardization, âInformation technology - 8-bit single byte coded graphic - character setsâ, 1987-1990.<br>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. 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,
@@ -2019,67 +2015,67 @@
</td>
</tr>
<tr>
- <td class="reference"><b id="RFC1900">[20]</b></td>
+ <td class="reference"><b id="RFC1900">[19]</b></td>
<td class="top"><a title="CERN, Computing and Networks Division">Carpenter, B.</a> and <a title="cisco Systems">Y. Rekhter</a>, â<a href="http://tools.ietf.org/html/rfc1900">Renumbering Needs Work</a>â, RFC 1900, February 1996.
</td>
</tr>
<tr>
- <td class="reference"><b id="Pad1995">[21]</b></td>
+ <td class="reference"><b id="Pad1995">[20]</b></td>
<td class="top">Padmanabhan, V.N. and J.C. Mogul, âImproving HTTP Latencyâ, Computer Networks and ISDN Systems v. 28, pp. 25-35, Dec 1995.<br>Slightly revised version of paper in Proc. 2nd International WWW Conference '94: Mosaic and the Web, Oct. 1994, which is available
at <<a href="http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLatency.html">http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLatency.html</a>>.
</td>
</tr>
<tr>
- <td class="reference"><b id="Tou1998">[22]</b></td>
+ <td class="reference"><b id="Tou1998">[21]</b></td>
<td class="top"><a title="USC/Information Sciences Institute">Touch, J.</a>, <a title="USC/Information Sciences Institute">Heidemann, J.</a>, and <a title="USC/Information Sciences Institute">K. Obraczka</a>, â<a href="http://www.isi.edu/touch/pubs/http-perf96/">Analysis of HTTP Performance</a>â, ISI Research Report ISI/RR-98-463 (original report dated Aug.1996), Aug 1998, <<a href="http://www.isi.edu/touch/pubs/http-perf96/">http://www.isi.edu/touch/pubs/http-perf96/</a>>.
</td>
</tr>
<tr>
- <td class="reference"><b id="RFC1305">[23]</b></td>
+ <td class="reference"><b id="RFC1305">[22]</b></td>
<td class="top"><a title="University of Delaware, Electrical Engineering Department">Mills, D.</a>, â<a href="http://tools.ietf.org/html/rfc1305">Network Time Protocol (Version 3) Specification, Implementation</a>â, RFC 1305, March 1992.
</td>
</tr>
<tr>
- <td class="reference"><b id="Spe">[24]</b></td>
+ <td class="reference"><b id="Spe">[23]</b></td>
<td class="top">Spero, S., â<a href="http://sunsite.unc.edu/mdma-release/http-prob.html">Analysis of HTTP Performance Problems</a>â, <<a href="http://sunsite.unc.edu/mdma-release/http-prob.html">http://sunsite.unc.edu/mdma-release/http-prob.html</a>>.
</td>
</tr>
<tr>
- <td class="reference"><b id="RFC2068">[25]</b></td>
+ <td class="reference"><b id="RFC2068">[24]</b></td>
<td class="top"><a title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, <a title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a title="Digital Equipment Corporation, Western Research Laboratory">Mogul, J.</a>, <a title="MIT Laboratory for Computer Science">Nielsen, H.</a>, and <a title="MIT Laboratory for Computer Science">T. Berners-Lee</a>, â<a href="http://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>â, RFC 2068, January 1997.
</td>
</tr>
<tr>
- <td class="reference"><b id="RFC2119">[26]</b></td>
+ <td class="reference"><b id="RFC2119">[25]</b></td>
<td class="top"><a title="Harvard University">Bradner, S.</a>, â<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>â, BCP 14, RFC 2119, March 1997.
</td>
</tr>
<tr>
- <td class="reference"><b id="RFC2145">[27]</b></td>
+ <td class="reference"><b id="RFC2145">[26]</b></td>
<td class="top"><a title="Western Research Laboratory">Mogul, J.C.</a>, <a title="Department of Information and Computer Science">Fielding, R.T.</a>, <a title="MIT Laboratory for Computer Science">Gettys, J.</a>, and <a title="W3 Consortium">H.F. Nielsen</a>, â<a href="http://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>â, RFC 2145, May 1997.
</td>
</tr>
<tr>
- <td class="reference"><b id="Nie1997">[28]</b></td>
+ <td class="reference"><b id="Nie1997">[27]</b></td>
<td class="top">Nielsen, H.F.., Gettys, J., Prud'hommeaux, E., Lie, H., and C. Lilley, âNetwork Performance Effects of HTTP/1.1, CSS1, and PNGâ, Proceedings of ACM SIGCOMM '97, Cannes France, Sep 1997.</td>
</tr>
<tr>
- <td class="reference"><b id="RFC2396">[29]</b></td>
+ <td class="reference"><b id="RFC2396">[28]</b></td>
<td class="top"><a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="Department of Information and Computer Science">Fielding, R.T.</a>, and <a title="Xerox PARC">L. Masinter</a>, â<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>â, RFC 2396, August 1998.
</td>
</tr>
<tr>
- <td class="reference"><b id="RFC2616">[30]</b></td>
+ <td class="reference"><b id="RFC2616">[29]</b></td>
<td class="top"><a title="University of California, Irvine">Fielding, R.</a>, <a title="W3C">Gettys, J.</a>, <a title="Compaq Computer Corporation">Mogul, J.</a>, <a title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a title="Xerox Corporation">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, and <a title="W3C">T. Berners-Lee</a>, â<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>â, RFC 2616, June 1999.
</td>
</tr>
<tr>
- <td class="reference"><b id="RFC2617">[31]</b></td>
+ <td class="reference"><b id="RFC2617">[30]</b></td>
<td class="top"><a title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a title="Verisign Inc.">Hallam-Baker, P.M.</a>, <a title="AbiSource, Inc.">Hostetler, J.L.</a>, <a title="Agranat Systems, Inc.">Lawrence, S.D.</a>, <a title="Microsoft Corporation">Leach, P.J.</a>, Luotonen, A., and <a title="Open Market, Inc.">L. Stewart</a>, â<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>â, RFC 2617, June 1999.
</td>
</tr>
<tr>
- <td class="reference"><b id="RFC2324">[32]</b></td>
+ <td class="reference"><b id="RFC2324">[31]</b></td>
<td class="top"><a title="Xerox Palo Alto Research Center">Masinter, L.</a>, â<a href="http://tools.ietf.org/html/rfc2324">Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</a>â, RFC 2324, April 1998.
</td>
</tr>
@@ -2101,7 +2097,7 @@
and "application/http". The message/http type can be used to enclose a single HTTP request or response message, provided that
it obeys the MIME restrictions for all "message" types regarding line length and encodings. The application/http type can
be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed). The following is to be registered
- with IANA <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[14]</cite></a>.
+ with IANA <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[13]</cite></a>.
</p>
<p id="rfc.section.A.p.2"> </p>
<dl>
@@ -2199,7 +2195,7 @@
</ul>
<p id="rfc.section.D.p.3">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. Some implementations implement the Keep-Alive version of persistent connections described
- in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1" id="rfc.xref.RFC2068.3">Section 19.7.1</a> of RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[25]</cite></a>.
+ in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1" id="rfc.xref.RFC2068.3">Section 19.7.1</a> of RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[24]</cite></a>.
</p>
<h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a> <a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2>
<p id="rfc.section.D.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
@@ -2240,11 +2236,11 @@
a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 8.1</a>.
</p>
<p id="rfc.section.D.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in RFC
- 2068. <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[25]</cite></a>
+ 2068. <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[24]</cite></a>
</p>
<h2 id="rfc.section.D.3"><a href="#rfc.section.D.3">D.3</a> <a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2>
<p id="rfc.section.D.3.p.1">This specification has been carefully audited to correct and disambiguate key word usage; RFC 2068 had many problems in respect
- to the conventions laid out in RFC 2119 <a href="#RFC2119" id="rfc.xref.RFC2119.2"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[26]</cite></a>.
+ to the conventions laid out in RFC 2119 <a href="#RFC2119" id="rfc.xref.RFC2119.2"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[25]</cite></a>.
</p>
<p id="rfc.section.D.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
@@ -2257,7 +2253,7 @@
<p id="rfc.section.D.3.p.5">Transfer-coding had significant problems, particularly with interactions with chunked encoding. The solution is that transfer-codings
become as full fledged as content-codings. This involves adding an IANA registry for transfer-codings (separate from content
codings), a new header field (TE) and enabling trailer headers in the future. Transfer encoding is a major performance benefit,
- so it was worth fixing <a href="#Nie1997" id="rfc.xref.Nie1997.2"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[28]</cite></a>. TE also solves another, obscure, downward interoperability problem that could have occurred due to interactions between
+ so it was worth fixing <a href="#Nie1997" id="rfc.xref.Nie1997.2"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[27]</cite></a>. TE also solves another, obscure, downward interoperability problem that could have occurred due to interactions between
authentication trailers, chunked encoding and HTTP/1.0 clients.(Section <a href="#transfer.codings" title="Transfer Codings">3.4</a>, <a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">3.4.1</a>, and <a href="#header.te" id="rfc.xref.header.te.3" title="TE">8.5</a>)
</p>
<h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
@@ -2459,7 +2455,6 @@
<li class="indline1">request <a class="iref" href="#rfc.iref.r.1">1.3</a></li>
<li class="indline1">resource <a class="iref" href="#rfc.iref.r.3">1.3</a></li>
<li class="indline1">response <a class="iref" href="#rfc.iref.r.2">1.3</a></li>
- <li class="indline1"><em>RFC1036</em> <a class="iref" href="#rfc.xref.RFC1036.1">3.3.1</a>, <a class="iref" href="#RFC1036"><b>11</b></a></li>
<li class="indline1"><em>RFC1123</em> <a class="iref" href="#rfc.xref.RFC1123.1">3.3.1</a>, <a class="iref" href="#rfc.xref.RFC1123.2">8.3</a>, <a class="iref" href="#RFC1123"><b>11</b></a></li>
<li class="indline1"><em>RFC1305</em> <a class="iref" href="#rfc.xref.RFC1305.1">8.3</a>, <a class="iref" href="#RFC1305"><b>11</b></a></li>
<li class="indline1"><em>RFC1436</em> <a class="iref" href="#rfc.xref.RFC1436.1">1.1</a>, <a class="iref" href="#RFC1436"><b>11</b></a></li>
Modified: labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml?rev=591538&r1=591537&r2=591538&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml Fri Nov 2 19:23:16 2007
@@ -1037,14 +1037,14 @@
</t>
<figure><artwork type="example">
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
+ Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
</artwork></figure>
<t>
The first format is preferred as an Internet standard and represents
a fixed-length subset of that defined by RFC 1123 <xref target="RFC1123"/> (an update to
- RFC 822 <xref target="RFC822"/>). The second format is in common use, but is based on the
- obsolete RFC 850 <xref target="RFC1036"/> date format and lacks a four-digit year.
+ RFC 822 <xref target="RFC822"/>). The other formats are described here only for
+ compatibility with obsolete implementations.
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
@@ -3150,17 +3150,6 @@
<date month="June" year="1995"/>
</front>
<seriesInfo name="RFC" value="1808"/>
-</reference>
-
-<reference anchor="RFC1036">
-<front>
-<title abbrev="Standard for USENET Messages">Standard for interchange of USENET messages</title>
-<author initials="M." surname="Horton" fullname="M. Horton">
-<organization>AT&amp;T Bell Laboratories</organization></author>
-<author initials="R." surname="Adams" fullname="R. Adams">
-<organization>Center for Seismic Studies</organization></author>
-<date month="December" year="1987"/></front>
-<seriesInfo name="RFC" value="1036"/>
</reference>
<reference anchor="RFC977">
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org