You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@labs.apache.org by re...@apache.org on 2007/12/10 22:51:27 UTC
svn commit: r603063 [1/4] - /labs/webarch/trunk/http/draft-fielding-http/
Author: reschke
Date: Mon Dec 10 13:51:25 2007
New Revision: 603063
URL: http://svn.apache.org/viewvc?rev=603063&view=rev
Log:
Make use of cross-document link feature (also add referenced Parts to references section).
Modified:
labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html
labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml
labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html
labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml
labs/webarch/trunk/http/draft-fielding-http/p3-payload.html
labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml
labs/webarch/trunk/http/draft-fielding-http/p4-conditional.html
labs/webarch/trunk/http/draft-fielding-http/p4-conditional.xml
labs/webarch/trunk/http/draft-fielding-http/p5-range.html
labs/webarch/trunk/http/draft-fielding-http/p5-range.xml
labs/webarch/trunk/http/draft-fielding-http/p6-cache.html
labs/webarch/trunk/http/draft-fielding-http/p6-cache.xml
labs/webarch/trunk/http/draft-fielding-http/p7-auth.html
labs/webarch/trunk/http/draft-fielding-http/p7-auth.xml
labs/webarch/trunk/http/draft-fielding-http/p8-cookies.html
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=603063&r1=603062&r2=603063&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html Mon Dec 10 13:51:25 2007
@@ -646,21 +646,19 @@
</p>
<dl class="empty">
<dd>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 [Part 3].
+ entity-header fields and content in the form of an entity-body, as described in <a href="http://tools.ietf.org/html/draft-fielding-p3-payload-latest" title="Entity">Section 3</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
</dd>
</dl>
<p id="rfc.section.1.3.p.8"> <span id="rfc.iref.r.4"></span> <dfn>representation</dfn>
</p>
<dl class="empty">
- <dd>An entity included with a response that is subject to content negotiation, as described in [Part 3]. There may exist multiple
- representations associated with a particular response status.
+ <dd>An entity included with a response that is subject to content negotiation, as described in <a href="http://tools.ietf.org/html/draft-fielding-p3-payload-latest" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. There may exist multiple representations associated with a particular response status.
</dd>
</dl>
<p id="rfc.section.1.3.p.9"> <span id="rfc.iref.c.2"></span> <dfn>content negotiation</dfn>
</p>
<dl class="empty">
- <dd>The mechanism for selecting the appropriate representation when servicing a request, as described in [Part 3]. The representation
- of entities in any response can be negotiated (including error responses).
+ <dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="http://tools.ietf.org/html/draft-fielding-p3-payload-latest" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. The representation of entities in any response can be negotiated (including error responses).
</dd>
</dl>
<p id="rfc.section.1.3.p.10"> <span id="rfc.iref.v.1"></span> <dfn>variant</dfn>
@@ -734,8 +732,8 @@
</p>
<dl class="empty">
<dd>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
- The rules for determining the cacheability of HTTP responses are defined in [Part 6]. Even if a resource is cacheable, there
- may be additional constraints on whether a cache can use the cached copy for a particular request.
+ The rules for determining the cacheability of HTTP responses are defined in <a href="http://tools.ietf.org/html/draft-fielding-p6-cache-latest" title="Caching in HTTP">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular
+ request.
</dd>
</dl>
<p id="rfc.section.1.3.p.20"> <span id="rfc.iref.u.2"></span> <span id="rfc.iref.d.1"></span> <dfn>upstream</dfn>/<dfn>downstream</dfn>
@@ -755,7 +753,7 @@
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 [Part 3].
+ entity-body content. The relationship between HTTP and MIME is described in <a href="http://tools.ietf.org/html/draft-fielding-p3-payload-latest" title="Differences Between HTTP Entities and RFC 2045 Entities">Section A</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
</p>
<p id="rfc.section.1.4.p.2">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
@@ -791,7 +789,7 @@
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chain
</pre><p id="rfc.section.1.4.p.9">Not all responses are usefully cacheable, and some requests may contain modifiers which place special requirements on cache
- behavior. HTTP requirements for cache behavior and cacheable responses are defined in [Part 6].
+ behavior. HTTP requirements for cache behavior and cacheable responses are defined in <a href="http://tools.ietf.org/html/draft-fielding-p6-cache-latest" title="Caching in HTTP">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
</p>
<p id="rfc.section.1.4.p.10">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,
@@ -900,7 +898,7 @@
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
</pre><p id="rfc.section.2.2.p.3">HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see <a href="#tolerant.applications" title="Tolerant Applications">Appendix B</a> for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described
- in [Part 3].
+ in <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
</p>
<div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.13"></span> CRLF = CR LF
</pre><p id="rfc.section.2.2.p.5">HTTP/1.1 header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal
@@ -978,7 +976,7 @@
(URI): Generic Syntax and Semantics," RFC 2396 <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a> (which replaces RFCs 1738 <a href="#RFC1738" id="rfc.xref.RFC1738.3"><cite title="Uniform Resource Locators (URL)">[RFC1738]</cite></a> and RFC 1808 <a href="#RFC1808" id="rfc.xref.RFC1808.2"><cite title="Relative Uniform Resource Locators">[RFC1808]</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]).
+ <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 <a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
</p>
<p id="rfc.section.3.2.1.p.3"> </p>
<dl class="empty">
@@ -1073,9 +1071,9 @@
in determining the exact body length (<a href="#message.length" title="Message Length">Section 4.4</a>), or the desire to encrypt data over a shared transport.
</p>
<p id="rfc.section.3.4.p.8">The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry
- contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.4.1</a>), "gzip" ([Part 3]), "compress" ([Part 3]), and "deflate" ([Part 3]).
+ contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.4.1</a>), "gzip" (<a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), "compress" (<a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and "deflate" (<a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
</p>
- <p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens ([Part 3]).
+ <p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
</p>
<p id="rfc.section.3.4.p.10">A server which receives an entity-body with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> return 501 (Unimplemented), and close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
</p>
@@ -1158,8 +1156,7 @@
by the BNF, an HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF.
</p>
<h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="message.headers" href="#message.headers">Message Headers</a></h2>
- <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section 4.5</a>), request-header ([Part 2]), response-header ([Part 2]), and entity-header ([Part 3]) fields, follow the same generic format
- as that given in <a href="http://tools.ietf.org/html/rfc822#section-3.1" id="rfc.xref.RFC822.5">Section 3.1</a> of RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.6"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The
+ <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section 4.5</a>), request-header (<a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="http://tools.ietf.org/html/draft-fielding-p3-payload-latest" title="Entity Header Fields">Section 3.1</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) fields, follow the same generic format as that given in <a
href="http://tools.ietf.org/html/rfc822#section-3.1" id="rfc.xref.RFC822.5">Section 3.1</a> of RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.6"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The
field value <em class="bcp14">MAY</em> 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 ought to follow "common form", where one is known or indicated, when
generating HTTP constructs, since there might exist some implementations that fail to accept anything beyond the common forms.
@@ -1195,8 +1192,7 @@
</p>
<p id="rfc.section.4.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p>
<p id="rfc.section.4.3.p.5">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 <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method ([Part 2]) does not allow sending an entity-body in requests.
- A server <em class="bcp14">SHOULD</em> read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body,
+ in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method (<a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest" title="Method">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) does not allow sending an entity-body in requests. A server <em class="bcp14">SHOULD</em> read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body,
then the message-body <em class="bcp14">SHOULD</em> be ignored when handling the request.
</p>
<p id="rfc.section.4.3.p.6">For response messages, whether or not a message-body is included with a message is dependent on both the request method and
@@ -1256,15 +1252,15 @@
<p id="rfc.section.4.5.p.1">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.
</p>
- <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.59"></span> general-header = Cache-Control ; [Part 6]
+ <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.59"></span> general-header = Cache-Control ; <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="http://tools.ietf.org/html/draft-fielding-p6-cache-latest" title="Cache-Control">Section 3.2</a>
| Connection ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a>
| Date ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 8.3</a>
- | Pragma ; [Part 6]
+ | Pragma ; <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="http://tools.ietf.org/html/draft-fielding-p6-cache-latest" title="Pragma">Section 3.4</a>
| Trailer ; <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 8.6</a>
| Transfer-Encoding ; <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section 8.7</a>
| Upgrade ; <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 8.8</a>
| Via ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 8.9</a>
- | Warning ; [Part 6]
+ | Warning ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="http://tools.ietf.org/html/draft-fielding-p6-cache-latest" title="Warning">Section 3.6</a>
</pre><p id="rfc.section.4.5.p.3">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.
@@ -1275,8 +1271,8 @@
</p>
<div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.60"></span> Request = Request-Line ; <a href="#request-line" title="Request-Line">Section 5.1</a>
*(( general-header ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a>
- | request-header ; [Part 2]
- | entity-header ) CRLF) ; [Part 3]
+ | request-header ; <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest" title="Request Header Fields">Section 4</a>
+ | entity-header ) CRLF) ; <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="http://tools.ietf.org/html/draft-fielding-p3-payload-latest" title="Entity Header Fields">Section 3.1</a>
CRLF
[ message-body ] ; <a href="#message.body" title="Message Body">Section 4.3</a>
</pre><h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="request-line" href="#request-line">Request-Line</a></h2>
@@ -1307,7 +1303,8 @@
<div id="rfc.figure.u.32"></div><pre class="text"> GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
</pre><p id="rfc.section.5.1.2.p.7">To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
</p>
- <p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method ([Part 2]).</p>
+ <p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method (<a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest" title="CONNECT">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
+ </p>
<p id="rfc.section.5.1.2.p.9">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 <em class="bcp14">MUST</em> be transmitted (see <a href="#general.syntax" title="General Syntax">Section 3.2.1</a>, abs_path) as the Request-URI, and the network location of the URI (authority) <em class="bcp14">MUST</em> 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.example.org" and send the lines:
@@ -1352,8 +1349,8 @@
<p id="rfc.section.6.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p>
<div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.65"></span> Response = Status-Line ; <a href="#status-line" title="Status-Line">Section 6.1</a>
*(( general-header ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a>
- | response-header ; [Part 2]
- | entity-header ) CRLF) ; [Part 3]
+ | response-header ; <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest" title="Response Header Fields">Section 6</a>
+ | entity-header ) CRLF) ; <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="http://tools.ietf.org/html/draft-fielding-p3-payload-latest" title="Entity Header Fields">Section 3.1</a>
CRLF
[ message-body ] ; <a href="#message.body" title="Message Body">Section 4.3</a>
</pre><h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="status-line" href="#status-line">Status-Line</a></h2>
@@ -1364,9 +1361,8 @@
<div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.66"></span> Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
</pre><h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>
<p id="rfc.section.6.1.1.p.1">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 [Part 2]. 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.
+ are fully defined in <a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest" title="Status Code Definitions">Section 9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. 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.
</p>
<p id="rfc.section.6.1.1.p.2">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:
@@ -1434,8 +1430,8 @@
</p>
<p id="rfc.section.7.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
</p>
- <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see [Part 2]). Otherwise, a premature
- termination of the transport connection could lead to indeterminate results. A client wishing to send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status for the previous request.
+ <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
+ send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status for the previous request.
</p>
<h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a> <a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3>
<p id="rfc.section.7.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 8.1</a>.
@@ -1459,7 +1455,7 @@
while it was idle, but from the client's point of view, a request is in progress.
</p>
<p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
- sequence is idempotent (see [Part 2]). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
+ sequence is idempotent (see <a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
</p>
<p id="rfc.section.7.1.4.p.5">Servers <em class="bcp14">SHOULD</em> always respond to at least one request per connection, if at all possible. Servers <em class="bcp14">SHOULD NOT</em> close a connection in the middle of transmitting a response, unless a network or client failure is suspected.
@@ -1477,17 +1473,16 @@
it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client <em class="bcp14">MUST</em> close the connection.
</p>
<h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
- <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see [Part 2]) is to allow a client that is sending a request message with a request
- body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends
- the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if
- the server will reject the message without looking at the body.
+ <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see <a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest" title="100 Continue">Section 9.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
+ to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either
+ be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking
+ at the body.
</p>
<p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
<ul>
- <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field ([Part 2]) with the "100-continue" expectation.
+ <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest" title="Expect">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
</li>
- <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field ([Part 2]) with the "100-continue" expectation if it does not intend to send a request
- body.
+ <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest" title="Expect">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
</li>
</ul>
<p id="rfc.section.7.2.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client may send "Expect:
@@ -1531,7 +1526,7 @@
</li>
<li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include
an Expect request-header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding
- of 1xx responses (see [Part 2]).
+ of 1xx responses (see <a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest" title="Informational 1xx">Section 9.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
</li>
</ul>
<h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a> <a id="connection.premature" href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></h3>
@@ -1697,7 +1692,7 @@
</li>
<li>
<p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it
- is accompanied by a qvalue of 0. (As defined in [Part 3], a qvalue of 0 means "not acceptable.")
+ is accompanied by a qvalue of 0. (As defined in <a href="http://tools.ietf.org/html/draft-fielding-p3-payload-latest" title="Quality Values">Section 2.4</a> of <a href="#Part3" id="rfc.xref.Part3.13"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.")
</p>
</li>
<li>
@@ -1925,7 +1920,7 @@
</pre><p id="rfc.section.11.p.5">Based on an XML translation of RFC 2616 by Julian Reschke.</p>
<h1 id="rfc.references"><a href="#rfc.section.12" id="rfc.section.12">12.</a> References
</h1>
- <table summary="References">
+ <table summary="References">
<tr>
<td class="reference"><b id="ISO-8859">[ISO-8859]</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.
@@ -1945,6 +1940,21 @@
</td>
</tr>
<tr>
+ <td class="reference"><b id="Part2">[Part2]</b></td>
+ <td class="top"><a title="Day Software">Fielding, R., Ed.</a>, <a title="One Laptop per Child">Gettys, J.</a>, <a title="Hewlett-Packard Company">Mogul, J.</a>, <a title="Microsoft Corporation">Frystyk, H.</a>, <a title="Adobe Systems, Incorporated">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, and <a title="World Wide Web Consortium">T. Berners-Lee</a>, â<a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest">HTTP/1.1, part 2: Message Semantics</a>â, Internet-Draft draft-fielding-p2-semantics-latest (work in progress), December 2007.
+ </td>
+ </tr>
+ <tr>
+ <td class="reference"><b id="Part3">[Part3]</b></td>
+ <td class="top"><a title="Day Software">Fielding, R., Ed.</a>, <a title="One Laptop per Child">Gettys, J.</a>, <a title="Hewlett-Packard Company">Mogul, J.</a>, <a title="Microsoft Corporation">Frystyk, H.</a>, <a title="Adobe Systems, Incorporated">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, and <a title="World Wide Web Consortium">T. Berners-Lee</a>, â<a href="http://tools.ietf.org/html/draft-fielding-p3-payload-latest">HTTP/1.1, part 3: Message Payload and Content Negotiation</a>â, Internet-Draft draft-fielding-p3-payload-latest (work in progress), December 2007.
+ </td>
+ </tr>
+ <tr>
+ <td class="reference"><b id="Part6">[Part6]</b></td>
+ <td class="top"><a title="Day Software">Fielding, R., Ed.</a>, <a title="One Laptop per Child">Gettys, J.</a>, <a title="Hewlett-Packard Company">Mogul, J.</a>, <a title="Microsoft Corporation">Frystyk, H.</a>, <a title="Adobe Systems, Incorporated">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, and <a title="World Wide Web Consortium">T. Berners-Lee</a>, â<a href="http://tools.ietf.org/html/draft-fielding-p6-cache-latest">HTTP/1.1, part 6: Caching</a>â, Internet-Draft draft-fielding-p6-cache-latest (work in progress), December 2007.
+ </td>
+ </tr>
+ <tr>
<td class="reference"><b id="RFC1123">[RFC1123]</b></td>
<td class="top"><a title="University of Southern California (USC), Information Sciences Institute">Braden, R.</a>, â<a href="http://tools.ietf.org/html/rfc1123">Requirements for Internet Hosts - Application and Support</a>â, STD 3, RFC 1123, October 1989.
</td>
@@ -2161,7 +2171,7 @@
such headers, recognize a single LF as a line terminator and ignore the leading CR.
</p>
<p id="rfc.section.B.p.4">The character set of an entity-body <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that body, with the exception that not labeling
- the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See [Part 3].
+ the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.14"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
</p>
<p id="rfc.section.B.p.5">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p>
<p id="rfc.section.B.p.6"> </p>
@@ -2448,6 +2458,34 @@
</li>
<li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
<li class="indline1"><em>Pad1995</em> <a class="iref" href="#rfc.xref.Pad1995.1">7.1.1</a>, <a class="iref" href="#Pad1995"><b>12</b></a></li>
+ <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">3.2.1</a>, <a class="iref" href="#rfc.xref.Part2.2">4.2</a>, <a class="iref" href="#rfc.xref.Part2.3">4.2</a>, <a class="iref" href="#rfc.xref.Part2.4">4.3</a>, <a class="iref" href="#rfc.xref.Part2.5">5</a>, <a class="iref" href="#rfc.xref.Part2.6">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.7">6</a>, <a class="iref" href="#rfc.xref.Part2.8">6.1.1</a>, <a class="iref" href="#rfc.xref.Part2.9">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.10">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#Part2"><b>12</b></a><ul class="ind">
+ <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.Part2.4">4.3</a></li>
+ <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part2.2">4.2</a>, <a class="iref" href="#rfc.xref.Part2.5">5</a></li>
+ <li class="indline1"><em>Section 6</em> <a class="iref" href="#rfc.xref.Part2.3">4.2</a>, <a class="iref" href="#rfc.xref.Part2.7">6</a></li>
+ <li class="indline1"><em>Section 8.1.2</em> <a class="iref" href="#rfc.xref.Part2.9">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.10">7.1.4</a></li>
+ <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part2.6">5.1.2</a></li>
+ <li class="indline1"><em>Section 9</em> <a class="iref" href="#rfc.xref.Part2.8">6.1.1</a></li>
+ <li class="indline1"><em>Section 9.1.1</em> <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a></li>
+ <li class="indline1"><em>Section 9.1</em> <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a></li>
+ <li class="indline1"><em>Section 9.4.15</em> <a class="iref" href="#rfc.xref.Part2.1">3.2.1</a></li>
+ <li class="indline1"><em>Section 10.2</em> <a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li>
+ </ul>
+ </li>
+ <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1.3</a>, <a class="iref" href="#rfc.xref.Part3.2">1.3</a>, <a class="iref" href="#rfc.xref.Part3.3">1.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.4</a>, <a class="iref" href="#rfc.xref.Part3.5">2.2</a>, <a class="iref" href="#rfc.xref.Part3.6">3.4</a>, <a class="iref" href="#rfc.xref.Part3.7">3.4</a>, <a class="iref" href="#rfc.xref.Part3.8">3.4</a>, <a class="iref" href="#rfc.xref.Part3.9">3.4</a>, <a class="iref" href="#rfc.xref.Part3.10">4.2</a>, <a class="iref" href="#rfc.xref.Part3.11">5</a>, <a class="iref" href="#rfc.xref.Part3.12">6</a>, <a class="iref" href="#rfc.xref.Part3.13">8.5</a>, <a class="iref" href="#Part3"><b>12</b></a>, <a class="iref" href="#rfc.xref.Part3.14">B</a><ul class="ind">
+ <li class="indline1"><em>Section 2.4</em> <a class="iref" href="#rfc.xref.Part3.13">8.5</a></li>
+ <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.Part3.1">1.3</a></li>
+ <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part3.10">4.2</a>, <a class="iref" href="#rfc.xref.Part3.11">5</a>, <a class="iref" href="#rfc.xref.Part3.12">6</a></li>
+ <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.2">1.3</a>, <a class="iref" href="#rfc.xref.Part3.3">1.3</a></li>
+ <li class="indline1"><em>Section A</em> <a class="iref" href="#rfc.xref.Part3.4">1.4</a></li>
+ </ul>
+ </li>
+ <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.4</a>, <a class="iref" href="#rfc.xref.Part6.3">4.5</a>, <a class="iref" href="#rfc.xref.Part6.4">4.5</a>, <a class="iref" href="#rfc.xref.Part6.5">4.5</a>, <a class="iref" href="#Part6"><b>12</b></a><ul class="ind">
+ <li class="indline1"><em>Section 2</em> <a class="iref" href="#rfc.xref.Part6.1">1.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.4</a></li>
+ <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part6.3">4.5</a></li>
+ <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part6.4">4.5</a></li>
+ <li class="indline1"><em>Section 3.6</em> <a class="iref" href="#rfc.xref.Part6.5">4.5</a></li>
+ </ul>
+ </li>
<li class="indline1">proxy <a class="iref" href="#rfc.iref.p.1">1.3</a></li>
</ul>
</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=603063&r1=603062&r2=603063&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml Mon Dec 10 13:51:25 2007
@@ -11,26 +11,28 @@
<!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
<!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
<!ENTITY ID-VERSION "latest">
- <!ENTITY caching "[Part 6]">
- <!ENTITY payload "[Part 3]">
- <!ENTITY CONNECT "[Part 2]">
- <!ENTITY content.negotiation "[Part 3]">
- <!ENTITY diff2045entity "[Part 3]">
- <!ENTITY entity "[Part 3]">
- <!ENTITY entity-header-fields "[Part 3]">
- <!ENTITY header-cache-control "[Part 6]">
- <!ENTITY header-expect "[Part 2]">
- <!ENTITY header-pragma "[Part 6]">
- <!ENTITY header-warning "[Part 6]">
- <!ENTITY idempotent-methods "[Part 2]">
- <!ENTITY qvalue "[Part 3]">
- <!ENTITY request-header-fields "[Part 2]">
- <!ENTITY response-header-fields "[Part 2]">
- <!ENTITY method "[Part 2]">
- <!ENTITY status-codes "[Part 2]">
- <!ENTITY status-100 "[Part 2]">
- <!ENTITY status-1xx "[Part 2]">
- <!ENTITY status-414 "[Part 2]">
+ <!ENTITY ID-MONTH "December">
+ <!ENTITY ID-YEAR "2007">
+ <!ENTITY caching "<xref target='Part6' x:rel='#caching' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY payload "<xref target='Part3' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY CONNECT "<xref target='Part2' x:rel='#CONNECT' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY content.negotiation "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY diff2045entity "<xref target='Part3' x:rel='#differences.between.http.entities.and.rfc.2045.entities' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY entity "<xref target='Part3' x:rel='#entity' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY entity-header-fields "<xref target='Part3' x:rel='#entity.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY header-cache-control "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY header-expect "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY header-pragma "<xref target='Part6' x:rel='#header.pragma' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY header-warning "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY idempotent-methods "<xref target='Part2' x:rel='#idempotent.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY qvalue "<xref target='Part3' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY request-header-fields "<xref target='Part2' x:rel='#request.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY response-header-fields "<xref target='Part2' x:rel='#response.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY method "<xref target='Part2' x:rel='#method' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY status-codes "<xref target='Part2' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY status-100 "<xref target='Part2' x:rel='#status.100' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY status-1xx "<xref target='Part2' x:rel='#status.1xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY status-414 "<xref target='Part2' x:rel='#status.414' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
@@ -153,7 +155,7 @@
</address>
</author>
- <date month="December" year="2007"/>
+ <date month="&ID-MONTH;" year="&ID-YEAR;"/>
<abstract>
<t>
@@ -2860,6 +2862,351 @@
</middle>
<back>
<references>
+
+<reference anchor="Part2">
+ <front>
+ <title abbrev="HTTP/1.1">HTTP/1.1, part 2: Message Semantics</title>
+
+ <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
+ <organization abbrev="Day Software">Day Software</organization>
+ <address>
+ <postal>
+ <street>23 Corporate Plaza DR, Suite 280</street>
+ <city>Newport Beach</city>
+ <region>CA</region>
+ <code>92660</code>
+ <country>USA</country>
+ </postal>
+ <phone>+1-949-706-5300</phone>
+ <facsimile>+1-949-706-5305</facsimile>
+ <email>fielding@gbiv.com</email>
+ <uri>http://roy.gbiv.com/</uri>
+ </address>
+ </author>
+
+ <author initials="J." surname="Gettys" fullname="Jim Gettys">
+ <organization>One Laptop per Child</organization>
+ <address>
+ <postal>
+ <street>21 Oak Knoll Road</street>
+ <city>Carlisle</city>
+ <region>MA</region>
+ <code>01741</code>
+ <country>USA</country>
+ </postal>
+ <email>jg@laptop.org</email>
+ <uri>http://www.laptop.org/</uri>
+ </address>
+ </author>
+
+ <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
+ <organization abbrev="HP">Hewlett-Packard Company</organization>
+ <address>
+ <postal>
+ <street>HP Labs, Large Scale Systems Group</street>
+ <street>1501 Page Mill Road, MS 1177</street>
+ <city>Palo Alto</city>
+ <region>CA</region>
+ <code>94304</code>
+ <country>USA</country>
+ </postal>
+ <email>JeffMogul@acm.org</email>
+ </address>
+ </author>
+
+ <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
+ <organization abbrev="Microsoft">Microsoft Corporation</organization>
+ <address>
+ <postal>
+ <street>1 Microsoft Way</street>
+ <city>Redmond</city>
+ <region>WA</region>
+ <code>98052</code>
+ <country>USA</country>
+ </postal>
+ <email>henrikn@microsoft.com</email>
+ </address>
+ </author>
+
+ <author initials="L." surname="Masinter" fullname="Larry Masinter">
+ <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
+ <address>
+ <postal>
+ <street>345 Park Ave</street>
+ <city>San Jose</city>
+ <region>CA</region>
+ <code>95110</code>
+ <country>USA</country>
+ </postal>
+ <email>LMM@acm.org</email>
+ <uri>http://larry.masinter.net/</uri>
+ </address>
+ </author>
+
+ <author initials="P." surname="Leach" fullname="Paul J. Leach">
+ <organization abbrev="Microsoft">Microsoft Corporation</organization>
+ <address>
+ <postal>
+ <street>1 Microsoft Way</street>
+ <city>Redmond</city>
+ <region>WA</region>
+ <code>98052</code>
+ </postal>
+ <email>paulle@microsoft.com</email>
+ </address>
+ </author>
+
+ <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+ <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city>
+ <region>MA</region>
+ <code>02139</code>
+ <country>USA</country>
+ </postal>
+ <facsimile>+1 (617) 258 8682</facsimile>
+ <email>timbl@w3.org</email>
+ </address>
+ </author>
+
+ <date month="&ID-MONTH;" year="&ID-YEAR;"/>
+ </front>
+ <seriesInfo name="Internet-Draft" value="draft-fielding-p2-semantics-&ID-VERSION;"/>
+ <x:source href="p2-semantics.xml"/>
+</reference>
+
+<reference anchor="Part3">
+ <front>
+ <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title>
+
+ <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
+ <organization abbrev="Day Software">Day Software</organization>
+ <address>
+ <postal>
+ <street>23 Corporate Plaza DR, Suite 280</street>
+ <city>Newport Beach</city>
+ <region>CA</region>
+ <code>92660</code>
+ <country>USA</country>
+ </postal>
+ <phone>+1-949-706-5300</phone>
+ <facsimile>+1-949-706-5305</facsimile>
+ <email>fielding@gbiv.com</email>
+ <uri>http://roy.gbiv.com/</uri>
+ </address>
+ </author>
+
+ <author initials="J." surname="Gettys" fullname="Jim Gettys">
+ <organization>One Laptop per Child</organization>
+ <address>
+ <postal>
+ <street>21 Oak Knoll Road</street>
+ <city>Carlisle</city>
+ <region>MA</region>
+ <code>01741</code>
+ <country>USA</country>
+ </postal>
+ <email>jg@laptop.org</email>
+ <uri>http://www.laptop.org/</uri>
+ </address>
+ </author>
+
+ <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
+ <organization abbrev="HP">Hewlett-Packard Company</organization>
+ <address>
+ <postal>
+ <street>HP Labs, Large Scale Systems Group</street>
+ <street>1501 Page Mill Road, MS 1177</street>
+ <city>Palo Alto</city>
+ <region>CA</region>
+ <code>94304</code>
+ <country>USA</country>
+ </postal>
+ <email>JeffMogul@acm.org</email>
+ </address>
+ </author>
+
+ <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
+ <organization abbrev="Microsoft">Microsoft Corporation</organization>
+ <address>
+ <postal>
+ <street>1 Microsoft Way</street>
+ <city>Redmond</city>
+ <region>WA</region>
+ <code>98052</code>
+ <country>USA</country>
+ </postal>
+ <email>henrikn@microsoft.com</email>
+ </address>
+ </author>
+
+ <author initials="L." surname="Masinter" fullname="Larry Masinter">
+ <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
+ <address>
+ <postal>
+ <street>345 Park Ave</street>
+ <city>San Jose</city>
+ <region>CA</region>
+ <code>95110</code>
+ <country>USA</country>
+ </postal>
+ <email>LMM@acm.org</email>
+ <uri>http://larry.masinter.net/</uri>
+ </address>
+ </author>
+
+ <author initials="P." surname="Leach" fullname="Paul J. Leach">
+ <organization abbrev="Microsoft">Microsoft Corporation</organization>
+ <address>
+ <postal>
+ <street>1 Microsoft Way</street>
+ <city>Redmond</city>
+ <region>WA</region>
+ <code>98052</code>
+ </postal>
+ <email>paulle@microsoft.com</email>
+ </address>
+ </author>
+
+ <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+ <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city>
+ <region>MA</region>
+ <code>02139</code>
+ <country>USA</country>
+ </postal>
+ <facsimile>+1 (617) 258 8682</facsimile>
+ <email>timbl@w3.org</email>
+ </address>
+ </author>
+
+ <date month="&ID-MONTH;" year="&ID-YEAR;"/>
+ </front>
+ <seriesInfo name="Internet-Draft" value="draft-fielding-p3-payload-&ID-VERSION;"/>
+ <x:source href="p3-payload.xml"/>
+</reference>
+
+<reference anchor="Part6">
+ <front>
+ <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title>
+
+ <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
+ <organization abbrev="Day Software">Day Software</organization>
+ <address>
+ <postal>
+ <street>23 Corporate Plaza DR, Suite 280</street>
+ <city>Newport Beach</city>
+ <region>CA</region>
+ <code>92660</code>
+ <country>USA</country>
+ </postal>
+ <phone>+1-949-706-5300</phone>
+ <facsimile>+1-949-706-5305</facsimile>
+ <email>fielding@gbiv.com</email>
+ <uri>http://roy.gbiv.com/</uri>
+ </address>
+ </author>
+
+ <author initials="J." surname="Gettys" fullname="Jim Gettys">
+ <organization>One Laptop per Child</organization>
+ <address>
+ <postal>
+ <street>21 Oak Knoll Road</street>
+ <city>Carlisle</city>
+ <region>MA</region>
+ <code>01741</code>
+ <country>USA</country>
+ </postal>
+ <email>jg@laptop.org</email>
+ <uri>http://www.laptop.org/</uri>
+ </address>
+ </author>
+
+ <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
+ <organization abbrev="HP">Hewlett-Packard Company</organization>
+ <address>
+ <postal>
+ <street>HP Labs, Large Scale Systems Group</street>
+ <street>1501 Page Mill Road, MS 1177</street>
+ <city>Palo Alto</city>
+ <region>CA</region>
+ <code>94304</code>
+ <country>USA</country>
+ </postal>
+ <email>JeffMogul@acm.org</email>
+ </address>
+ </author>
+
+ <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
+ <organization abbrev="Microsoft">Microsoft Corporation</organization>
+ <address>
+ <postal>
+ <street>1 Microsoft Way</street>
+ <city>Redmond</city>
+ <region>WA</region>
+ <code>98052</code>
+ <country>USA</country>
+ </postal>
+ <email>henrikn@microsoft.com</email>
+ </address>
+ </author>
+
+ <author initials="L." surname="Masinter" fullname="Larry Masinter">
+ <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
+ <address>
+ <postal>
+ <street>345 Park Ave</street>
+ <city>San Jose</city>
+ <region>CA</region>
+ <code>95110</code>
+ <country>USA</country>
+ </postal>
+ <email>LMM@acm.org</email>
+ <uri>http://larry.masinter.net/</uri>
+ </address>
+ </author>
+
+ <author initials="P." surname="Leach" fullname="Paul J. Leach">
+ <organization abbrev="Microsoft">Microsoft Corporation</organization>
+ <address>
+ <postal>
+ <street>1 Microsoft Way</street>
+ <city>Redmond</city>
+ <region>WA</region>
+ <code>98052</code>
+ </postal>
+ <email>paulle@microsoft.com</email>
+ </address>
+ </author>
+
+ <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+ <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city>
+ <region>MA</region>
+ <code>02139</code>
+ <country>USA</country>
+ </postal>
+ <facsimile>+1 (617) 258 8682</facsimile>
+ <email>timbl@w3.org</email>
+ </address>
+ </author>
+
+ <date month="&ID-MONTH;" year="&ID-YEAR;"/>
+ </front>
+ <seriesInfo name="Internet-Draft" value="draft-fielding-p6-cache-&ID-VERSION;"/>
+ <x:source href="p6-cache.xml"/>
+</reference>
<reference anchor="RFC1436">
<front>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org