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 [2/4] - /labs/webarch/trunk/http/draft-fielding-http/
Modified: labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html?rev=603063&r1=603062&r2=603063&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html Mon Dec 10 13:51:25 2007
@@ -577,7 +577,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.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
</p>
<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h1>
<p id="rfc.section.2.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields
@@ -613,14 +613,14 @@
to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language
method invocation.
</p>
- <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.5"></span> request-header = Accept ; [Part 3]
- | Accept-Charset ; [Part 3]
- | Accept-Encoding ; [Part 3]
- | Accept-Language ; [Part 3]
+ <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.5"></span> request-header = Accept ; <a href="#Part3" id="rfc.xref.Part3.2"><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="Accept">Section 5.1</a>
+ | Accept-Charset ; <a href="#Part3" id="rfc.xref.Part3.3"><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="Accept-Charset">Section 5.2</a>
+ | Accept-Encoding ; <a href="#Part3" id="rfc.xref.Part3.4"><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="Accept-Encoding">Section 5.3</a>
+ | Accept-Language ; <a href="#Part3" id="rfc.xref.Part3.5"><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="Accept-Language">Section 5.4</a>
| Authorization ; [Part 7]
| Expect ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 10.2</a>
| From ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 10.3</a>
- | Host ; [Part 1]
+ | Host ; <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest" title="Host">Section 8.4</a>
| If-Match ; [Part 4]
| If-Modified-Since ; [Part 4]
| If-None-Match ; [Part 4]
@@ -630,7 +630,7 @@
| Proxy-Authorization ; [Part 7]
| Range ; [Part 5]
| Referer ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 10.6</a>
- | TE ; [Part 1]
+ | TE ; <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest" title="Upgrade">Section 8.8</a>
| User-Agent ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 10.9</a>
</pre><p id="rfc.section.4.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new
or experimental header fields <em class="bcp14">MAY</em> be given the semantics of request-header fields if all parties in the communication recognize them to be request-header fields.
@@ -700,7 +700,7 @@
Status-Line. These header fields give information about the server and about further access to the resource identified by
the Request-URI.
</p>
- <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.9"></span> response-header = Accept-Ranges ; [Part 3]
+ <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.9"></span> response-header = Accept-Ranges ; <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="http://tools.ietf.org/html/draft-fielding-p5-range-latest" title="Accept-Ranges">Section 6.1</a>
| Age ; [Part 6]
| ETag ; [Part 4]
| Location ; <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 10.4</a>
@@ -716,15 +716,14 @@
<h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="entity" href="#entity">Entity</a></h1>
<p id="rfc.section.7.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header
fields and an entity-body, although some responses will only include the entity-headers. HTTP entity-body and entity-header
- fields are defined in [Part 3].
+ fields are defined in <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
</p>
- <p id="rfc.section.7.p.2">An entity-body is only present in a message when a message-body is present, as described in [Part 1]. The entity-body is obtained
- from the message-body by decoding any Transfer-Encoding that might have been applied to ensure safe and proper transfer of
- the message.
+ <p id="rfc.section.7.p.2">An entity-body is only present in a message when a message-body is present, as described in <a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest" title="Message Body">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
+ safe and proper transfer of the message.
</p>
<h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h1>
<p id="rfc.section.8.p.1">The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed
- to share the same semantics for separately extended clients and servers. The Host request-header field ([Part 1]) <em class="bcp14">MUST</em> accompany all HTTP/1.1 requests.
+ to share the same semantics for separately extended clients and servers. The Host request-header field (<a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest" title="Host">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) <em class="bcp14">MUST</em> accompany all HTTP/1.1 requests.
</p>
<h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2>
<h3 id="rfc.section.8.1.1"><a href="#rfc.section.8.1.1">8.1.1</a> <a id="safe.methods" href="#safe.methods">Safe Methods</a></h3>
@@ -799,7 +798,8 @@
reduce unnecessary network usage by allowing partially-retrieved entities to be completed without transferring data already
held by the client.
</p>
- <p id="rfc.section.8.3.p.4">The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in [Part 6].</p>
+ <p id="rfc.section.8.3.p.4">The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
+ </p>
<p id="rfc.section.8.3.p.5">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URI's">Section 12.2</a> for security considerations when used for forms.
</p>
<div id="rfc.iref.h.1"></div>
@@ -889,9 +889,9 @@
origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 10.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include an entity.
</p>
<p id="rfc.section.8.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
- or diagnostic information. The value of the Via header field ([Part 1]) is of particular interest, since it acts as a trace
- of the request chain. Use of the Max-Forwards header field allows the client to limit the length of the request chain, which
- is useful for testing a chain of proxies forwarding messages in an infinite loop.
+ or diagnostic information. The value of the Via header field (<a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
+ client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an
+ infinite loop.
</p>
<p id="rfc.section.8.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> contain the entire request message in the entity-body, with a Content-Type of "message/http". Responses to this method <em class="bcp14">MUST NOT</em> be cached.
</p>
@@ -922,14 +922,12 @@
<h3 id="rfc.section.9.1.1"><a href="#rfc.section.9.1.1">9.1.1</a> <a id="status.100" href="#status.100">100 Continue</a></h3>
<p id="rfc.section.9.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been
received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The
- server <em class="bcp14">MUST</em> send a final response after the request has been completed. See [Part 1] for detailed discussion of the use and handling of
- this status code.
+ server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
</p>
<div id="rfc.iref.26"></div>
<div id="rfc.iref.s.2"></div>
<h3 id="rfc.section.9.1.2"><a href="#rfc.section.9.1.2">9.1.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
- <p id="rfc.section.9.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field ([Part 1]),
- for a change in the application protocol being used on this connection. The server will switch protocols to those defined
+ <p id="rfc.section.9.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="http://tools.ietf.org/html/draft-fielding-p5-range-latest" title="Range">Section 6.4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
</p>
<p id="rfc.section.9.1.2.p.2">The protocol <em class="bcp14">SHOULD</em> be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over
@@ -1008,7 +1006,7 @@
<div id="rfc.iref.s.9"></div>
<h3 id="rfc.section.9.2.7"><a href="#rfc.section.9.2.7">9.2.7</a> <a id="status.206" href="#status.206">206 Partial Content</a></h3>
<p id="rfc.section.9.2.7.p.1">The server has fulfilled the partial GET request for the resource and the enclosed entity is a partial representation as defined
- in [Part 5].
+ in <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.
</p>
<h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
<p id="rfc.section.9.3.p.1">This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request.
@@ -1024,8 +1022,8 @@
<div id="rfc.iref.s.10"></div>
<h3 id="rfc.section.9.3.1"><a href="#rfc.section.9.3.1">9.3.1</a> <a id="status.300" href="#status.300">300 Multiple Choices</a></h3>
<p id="rfc.section.9.3.1.p.1">The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent-driven
- negotiation information ([Part 3]) is being provided so that the user (or user agent) can select a preferred representation
- and redirect its request to that location.
+ negotiation information (<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.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that
+ location.
</p>
<p id="rfc.section.9.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose
the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending
@@ -1101,7 +1099,7 @@
variant
</li>
</ul>
- <p id="rfc.section.9.3.5.p.4">If the conditional GET used a strong cache validator (see [Part 6]), the response <em class="bcp14">SHOULD NOT</em> include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response <em class="bcp14">MUST NOT</em> include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
+ <p id="rfc.section.9.3.5.p.4">If the conditional GET used a strong cache validator (see <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>), the response <em class="bcp14">SHOULD NOT</em> include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response <em class="bcp14">MUST NOT</em> include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
</p>
<p id="rfc.section.9.3.5.p.5">If a 304 response indicates an entity not currently cached, then the cache <em class="bcp14">MUST</em> disregard the response and repeat the request without the conditional.
</p>
@@ -1333,7 +1331,7 @@
<h3 id="rfc.section.9.5.6"><a href="#rfc.section.9.5.6">9.5.6</a> <a id="status.505" href="#status.505">505 HTTP Version Not Supported</a></h3>
<p id="rfc.section.9.5.6.p.1">The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server
is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
- in [Part 1], other than with this error message. The response <em class="bcp14">SHOULD</em> contain an entity describing why that version is not supported and what other protocols are supported by that server.
+ in <a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest" title="HTTP Version">Section 3.1</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain an entity describing why that version is not supported and what other protocols are supported by that server.
</p>
<h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
<p id="rfc.section.10.p.1">This section defines the syntax and semantics of all standard HTTP/1.1 header fields. For entity-header fields, both sender
@@ -1379,7 +1377,8 @@
request-header itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.
</p>
<p id="rfc.section.10.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.</p>
- <p id="rfc.section.10.2.p.8">See [Part 1] for the use of the 100 (continue) status.</p>
+ <p id="rfc.section.10.2.p.8">See <a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (continue) status.
+ </p>
<div id="rfc.iref.f.1"></div>
<div id="rfc.iref.h.4"></div>
<h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a> <a id="header.from" href="#header.from">From</a></h2>
@@ -1412,9 +1411,8 @@
<div id="rfc.figure.u.13"></div><pre class="text"> Location: http://www.example.org/pub/WWW/People.html
</pre><p id="rfc.section.10.4.p.5"> </p>
<dl class="empty">
- <dd> <b>Note:</b> The Content-Location header field ([Part 3]) differs from Location in that the Content-Location identifies the original location
- of the entity enclosed in the request. It is therefore possible for a response to contain header fields for both Location
- and Content-Location.
+ <dd> <b>Note:</b> The Content-Location header field (<a href="http://tools.ietf.org/html/draft-fielding-p3-payload-latest" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request.
+ It is therefore possible for a response to contain header fields for both Location and Content-Location.
</dd>
</dl>
<div id="rfc.iref.m.9"></div>
@@ -1466,7 +1464,7 @@
<div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.21"></span> Server = "Server" ":" 1*( product | comment )
</pre><p id="rfc.section.10.8.p.3">Example:</p>
<div id="rfc.figure.u.20"></div><pre class="text"> Server: CERN/3.0 libwww/2.17
-</pre><p id="rfc.section.10.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in [Part 1]).
+</pre><p id="rfc.section.10.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
</p>
<dl class="empty">
<dd> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
@@ -1538,12 +1536,32 @@
<p id="rfc.section.13.p.1">Based on an XML translation of RFC 2616 by Julian Reschke.</p>
<h1 id="rfc.references"><a href="#rfc.section.14" id="rfc.section.14">14.</a> References
</h1>
- <table summary="References">
+ <table summary="References">
<tr>
<td class="reference"><b id="Luo1998">[Luo1998]</b></td>
<td class="top">Luotonen, A., âTunneling TCP based protocols through Web proxy serversâ, Work in Progress.</td>
</tr>
<tr>
+ <td class="reference"><b id="Part1">[Part1]</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-p1-messaging-latest">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</a>â, Internet-Draft draft-fielding-p1-messaging-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="Part5">[Part5]</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-p5-range-latest">HTTP/1.1, part 5: Range Requests and Partial Responses</a>â, Internet-Draft draft-fielding-p5-range-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>
@@ -1785,6 +1803,31 @@
</ul>
</li>
<li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
+ <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">4</a>, <a class="iref" href="#rfc.xref.Part1.2">4</a>, <a class="iref" href="#rfc.xref.Part1.3">7</a>, <a class="iref" href="#rfc.xref.Part1.4">8</a>, <a class="iref" href="#rfc.xref.Part1.5">8.8</a>, <a class="iref" href="#rfc.xref.Part1.6">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.7">9.5.6</a>, <a class="iref" href="#rfc.xref.Part1.8">10.2</a>, <a class="iref" href="#rfc.xref.Part1.9">10.8</a>, <a class="iref" href="#Part1"><b>14</b></a><ul class="ind">
+ <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part1.7">9.5.6</a></li>
+ <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.3">7</a></li>
+ <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.6">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.8">10.2</a></li>
+ <li class="indline1"><em>Section 8.4</em> <a class="iref" href="#rfc.xref.Part1.1">4</a>, <a class="iref" href="#rfc.xref.Part1.4">8</a></li>
+ <li class="indline1"><em>Section 8.8</em> <a class="iref" href="#rfc.xref.Part1.2">4</a></li>
+ <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part1.5">8.8</a>, <a class="iref" href="#rfc.xref.Part1.9">10.8</a></li>
+ </ul>
+ </li>
+ <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">4</a>, <a class="iref" href="#rfc.xref.Part3.3">4</a>, <a class="iref" href="#rfc.xref.Part3.4">4</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">7</a>, <a class="iref" href="#rfc.xref.Part3.7">9.3.1</a>, <a class="iref" href="#rfc.xref.Part3.8">10.4</a>, <a class="iref" href="#Part3"><b>14</b></a><ul class="ind">
+ <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.7">9.3.1</a></li>
+ <li class="indline1"><em>Section 5.1</em> <a class="iref" href="#rfc.xref.Part3.2">4</a></li>
+ <li class="indline1"><em>Section 5.2</em> <a class="iref" href="#rfc.xref.Part3.3">4</a></li>
+ <li class="indline1"><em>Section 5.3</em> <a class="iref" href="#rfc.xref.Part3.4">4</a></li>
+ <li class="indline1"><em>Section 5.4</em> <a class="iref" href="#rfc.xref.Part3.5">4</a></li>
+ <li class="indline1"><em>Section 5.7</em> <a class="iref" href="#rfc.xref.Part3.8">10.4</a></li>
+ <li class="indline1"><em>Section A</em> <a class="iref" href="#rfc.xref.Part3.1">1</a></li>
+ </ul>
+ </li>
+ <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">6</a>, <a class="iref" href="#rfc.xref.Part5.2">9.1.2</a>, <a class="iref" href="#rfc.xref.Part5.3">9.2.7</a>, <a class="iref" href="#Part5"><b>14</b></a><ul class="ind">
+ <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part5.1">6</a></li>
+ <li class="indline1"><em>Section 6.4</em> <a class="iref" href="#rfc.xref.Part5.2">9.1.2</a></li>
+ </ul>
+ </li>
+ <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">8.3</a>, <a class="iref" href="#rfc.xref.Part6.2">9.3.5</a>, <a class="iref" href="#Part6"><b>14</b></a></li>
<li class="indline1">PATCH method <a class="iref" href="#rfc.iref.p.3"><b>A</b></a></li>
<li class="indline1">POST method <a class="iref" href="#rfc.xref.POST.1">3</a>, <a class="iref" href="#rfc.iref.p.1"><b>8.5</b></a></li>
<li class="indline1">PUT method <a class="iref" href="#rfc.xref.PUT.1">3</a>, <a class="iref" href="#rfc.iref.p.2"><b>8.6</b></a></li>
Modified: labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml?rev=603063&r1=603062&r2=603063&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml Mon Dec 10 13:51:25 2007
@@ -11,32 +11,34 @@
<!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 messaging "[Part 1]">
- <!ENTITY payload "[Part 3]">
- <!ENTITY conditional "[Part 4]">
- <!ENTITY range "[Part 5]">
- <!ENTITY caching "[Part 6]">
- <!ENTITY auth "[Part 7]">
- <!ENTITY content-negotiation "[Part 3]">
- <!ENTITY diff2045entity "[Part 3]">
- <!ENTITY uri "[Part 1]">
- <!ENTITY http-url "[Part 1]">
- <!ENTITY http-version "[Part 1]">
- <!ENTITY use100 "[Part 1]">
- <!ENTITY qvalue "[Part 3]">
- <!ENTITY header-accept "[Part 3]">
- <!ENTITY header-accept-charset "[Part 3]">
- <!ENTITY header-accept-encoding "[Part 3]">
- <!ENTITY header-accept-language "[Part 3]">
- <!ENTITY header-accept-ranges "[Part 3]">
+ <!ENTITY ID-MONTH "December">
+ <!ENTITY ID-YEAR "2007">
+ <!ENTITY messaging "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY payload "<xref target='Part3' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY conditional "<xref target='Part4' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY range "<xref target='Part5' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY caching "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY auth "<xref target='Part7' 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 uri "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY http-url "<xref target='Part1' x:rel='#http-url' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY http-version "<xref target='Part1' x:rel='#http.version' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY use100 "<xref target='Part1' x:rel='#use.of.the.100.status' 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 header-accept "<xref target='Part3' x:rel='#header.accept' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY header-accept-charset "<xref target='Part3' x:rel='#header.accept-charset' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY header-accept-encoding "<xref target='Part3' x:rel='#header.accept-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY header-accept-language "<xref target='Part3' x:rel='#header.accept-language' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY header-accept-ranges "<xref target='Part5' x:rel='#header.accept-ranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-age "[Part 6]">
<!ENTITY header-authorization "[Part 7]">
<!ENTITY header-cache-control "[Part 6]">
- <!ENTITY header-content-location "[Part 3]">
+ <!ENTITY header-content-location "<xref target='Part3' x:rel='#header.content-location' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-content-range "[Part 5]">
<!ENTITY header-etag "[Part 4]">
<!ENTITY header-expires "[Part 6]">
- <!ENTITY header-host "[Part 1]">
+ <!ENTITY header-host "<xref target='Part1' x:rel='#header.host' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-if-match "[Part 4]">
<!ENTITY header-if-modified-since "[Part 4]">
<!ENTITY header-if-none-match "[Part 4]">
@@ -46,13 +48,13 @@
<!ENTITY header-proxy-authenticate "[Part 7]">
<!ENTITY header-proxy-authorization "[Part 7]">
<!ENTITY header-range "[Part 5]">
- <!ENTITY header-upgrade "[Part 1]">
- <!ENTITY header-te "[Part 1]">
+ <!ENTITY header-upgrade "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+ <!ENTITY header-te "<xref target='Part1' x:rel='#header.upgrade' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-vary "[Part 6]">
- <!ENTITY header-via "[Part 1]">
+ <!ENTITY header-via "<xref target='Part1' x:rel='#header.via' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<!ENTITY header-warning "[Part 6]">
<!ENTITY header-www-authenticate "[Part 7]">
- <!ENTITY message-body "[Part 1]">
+ <!ENTITY message-body "<xref target='Part1' x:rel='#message.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
@@ -175,7 +177,7 @@
</address>
</author>
- <date month="December" year="2007"/>
+ <date month="&ID-MONTH;" year="&ID-YEAR;"/>
<abstract>
<t>
@@ -2075,6 +2077,466 @@
</middle>
<back>
<references>
+
+<reference anchor="Part1">
+ <front>
+ <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</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-p1-messaging-&ID-VERSION;"/>
+ <x:source href="p1-messaging.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="Part5">
+ <front>
+ <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</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-p5-range-&ID-VERSION;"/>
+ <x:source href="p5-range.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="RFC1123">
<front>
Modified: labs/webarch/trunk/http/draft-fielding-http/p3-payload.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p3-payload.html?rev=603063&r1=603062&r2=603063&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p3-payload.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p3-payload.html Mon Dec 10 13:51:25 2007
@@ -660,8 +660,7 @@
boundary.
</p>
<p id="rfc.section.2.3.2.p.2">In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. The one exception
- is the "multipart/byteranges" type ([Part 5]) when it appears in a 206 (Partial Content) response. In all other cases, an
- HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within
+ is the "multipart/byteranges" type (<a href="http://tools.ietf.org/html/draft-fielding-p5-range-latest" title="Internet Media Type multipart/byteranges">Section A</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) when it appears in a 206 (Partial Content) response. In all other cases, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within
each body-part of a multipart message-body do not have any significance to HTTP beyond that defined by their MIME semantics.
</p>
<p id="rfc.section.2.3.2.p.3">In general, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. If an application receives
@@ -709,16 +708,16 @@
<p id="rfc.section.3.1.p.1">Entity-header fields define metainformation about the entity-body or, if no body is present, about the resource identified
by the request. Some of this metainformation is <em class="bcp14">OPTIONAL</em>; some might be <em class="bcp14">REQUIRED</em> by portions of this specification.
</p>
- <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> entity-header = Allow ; [Part 2]
+ <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> entity-header = Allow ; <a href="#Part2" id="rfc.xref.Part2.1"><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="Allow">Section 10.1</a>
| Content-Encoding ; <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section 5.5</a>
| Content-Language ; <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section 5.6</a>
- | Content-Length ; [Part 1]
+ | Content-Length ; <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest" title="Content-Length">Section 8.2</a>
| Content-Location ; <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section 5.7</a>
| Content-MD5 ; <a href="#header.content-md5" id="rfc.xref.header.content-md5.1" title="Content-MD5">Section 5.8</a>
- | Content-Range ; [Part 5]
+ | Content-Range ; <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="http://tools.ietf.org/html/draft-fielding-p5-range-latest" title="Content-Range">Section 6.2</a>
| Content-Type ; <a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section 5.9</a>
- | Expires ; [Part 6]
- | Last-Modified ; [Part 4]
+ | Expires ; <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="http://tools.ietf.org/html/draft-fielding-p6-cache-latest" title="Expires">Section 3.3</a>
+ | Last-Modified ; <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="http://tools.ietf.org/html/draft-fielding-p4-conditional-latest" title="Last-Modified">Section 5.6</a>
| extension-header
extension-header = message-header
@@ -728,9 +727,8 @@
<h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="entity.body" href="#entity.body">Entity Body</a></h2>
<p id="rfc.section.3.2.p.1">The entity-body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.</p>
<div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.16"></span> entity-body = *OCTET
-</pre><p id="rfc.section.3.2.p.3">An entity-body is only present in a message when a message-body is present, as described in [Part 1]. The entity-body is obtained
- from the message-body by decoding any Transfer-Encoding that might have been applied to ensure safe and proper transfer of
- the message.
+</pre><p id="rfc.section.3.2.p.3">An entity-body is only present in a message when a message-body is present, as described in <a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest" title="Message Body">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
+ safe and proper transfer of the message.
</p>
<h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="type" href="#type">Type</a></h3>
<p id="rfc.section.3.2.1.p.1">When an entity-body is included with a message, the data type of that body is determined via the header fields Content-Type
@@ -746,8 +744,7 @@
resource. If the media type remains unknown, the recipient <em class="bcp14">SHOULD</em> treat it as type "application/octet-stream".
</p>
<h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="entity.length" href="#entity.length">Entity Length</a></h3>
- <p id="rfc.section.3.2.2.p.1">The entity-length of a message is the length of the message-body before any transfer-codings have been applied. [Part 1] defines
- how the transfer-length of a message-body is determined.
+ <p id="rfc.section.3.2.2.p.1">The entity-length of a message is the length of the message-body before any transfer-codings have been applied. <a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest" title="Message Length">Section 4.4</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> defines how the transfer-length of a message-body is determined.
</p>
<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1>
<p id="rfc.section.4.p.1">Most HTTP responses include an entity which contains information for interpretation by a human user. Naturally, it is desirable
@@ -792,11 +789,10 @@
<li>It may limit a public cache's ability to use the same response for multiple user's requests.</li>
</ol>
<p id="rfc.section.4.1.p.4">HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent
- capabilities and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 5.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 5.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 5.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 5.4</a>), and User-Agent ([Part 2]). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including information outside the request-header fields or within extension
+ capabilities and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 5.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 5.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 5.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 5.4</a>), and User-Agent (<a href="http://tools.ietf.org/html/draft-fielding-p2-semantics-latest" title="User-Agent">Section 10.9</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including information outside the request-header field
s or within extension
header fields not defined by this specification.
</p>
- <p id="rfc.section.4.1.p.5">The Vary header field [Part 6] can be used to express the parameters the server uses to select a representation that is subject
- to server-driven negotiation.
+ <p id="rfc.section.4.1.p.5">The Vary header field <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.
</p>
<h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2>
<p id="rfc.section.4.2.p.1">With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving
@@ -1074,7 +1070,7 @@
</p>
<p id="rfc.section.5.7.p.5">A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond
to later requests on that Content-Location URI. However, the Content-Location can be used to differentiate between multiple
- entities retrieved from a single requested resource, as described in [Part 6].
+ entities retrieved from a single requested resource, as described in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
</p>
<p id="rfc.section.5.7.p.6">If the Content-Location is a relative URI, the relative URI is interpreted relative to the Request-URI.</p>
<p id="rfc.section.5.7.p.7">The meaning of the Content-Location header in PUT or POST requests is undefined; servers are free to ignore it in those cases.</p>
@@ -1162,7 +1158,32 @@
<p id="rfc.section.8.p.1">Based on an XML translation of RFC 2616 by Julian Reschke.</p>
<h1 id="rfc.references"><a href="#rfc.section.9" id="rfc.section.9">9.</a> References
</h1>
- <table summary="References">
+ <table summary="References">
+ <tr>
+ <td class="reference"><b id="Part1">[Part1]</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-p1-messaging-latest">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</a>â, Internet-Draft draft-fielding-p1-messaging-latest (work in progress), December 2007.
+ </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="Part4">[Part4]</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-p4-conditional-latest">HTTP/1.1, part 4: Conditional Requests</a>â, Internet-Draft draft-fielding-p4-conditional-latest (work in progress), December 2007.
+ </td>
+ </tr>
+ <tr>
+ <td class="reference"><b id="Part5">[Part5]</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-p5-range-latest">HTTP/1.1, part 5: Range Requests and Partial Responses</a>â, Internet-Draft draft-fielding-p5-range-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="RFC1766">[RFC1766]</b></td>
<td class="top"><a title="UNINETT">Alvestrand, H.</a>, â<a href="http://tools.ietf.org/html/rfc1766">Tags for the Identification of Languages</a>â, RFC 1766, March 1995.
@@ -1311,7 +1332,7 @@
the destination protocol.
</p>
<h2 id="rfc.section.A.5"><a href="#rfc.section.A.5">A.5</a> <a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2>
- <p id="rfc.section.A.5.p.1">HTTP/1.1 introduces the Transfer-Encoding header field ([Part 1]). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
+ <p id="rfc.section.A.5.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="http://tools.ietf.org/html/draft-fielding-p1-messaging-latest" title="Transfer-Encoding">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
</p>
<h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2>
<p id="rfc.section.A.6.p.1">HTTP implementations which share code with MHTML <a href="#RFC2110" id="rfc.xref.RFC2110.1"><cite title="MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2110]</cite></a> implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not
@@ -1497,6 +1518,31 @@
</ul>
</li>
<li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
+ <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">3.1</a>, <a class="iref" href="#rfc.xref.Part1.2">3.2</a>, <a class="iref" href="#rfc.xref.Part1.3">3.2.2</a>, <a class="iref" href="#Part1"><b>9</b></a>, <a class="iref" href="#rfc.xref.Part1.4">A.5</a><ul class="ind">
+ <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.2">3.2</a></li>
+ <li class="indline1"><em>Section 4.4</em> <a class="iref" href="#rfc.xref.Part1.3">3.2.2</a></li>
+ <li class="indline1"><em>Section 8.2</em> <a class="iref" href="#rfc.xref.Part1.1">3.1</a></li>
+ <li class="indline1"><em>Section 8.7</em> <a class="iref" href="#rfc.xref.Part1.4">A.5</a></li>
+ </ul>
+ </li>
+ <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">3.1</a>, <a class="iref" href="#rfc.xref.Part2.2">4.1</a>, <a class="iref" href="#Part2"><b>9</b></a><ul class="ind">
+ <li class="indline1"><em>Section 10.1</em> <a class="iref" href="#rfc.xref.Part2.1">3.1</a></li>
+ <li class="indline1"><em>Section 10.9</em> <a class="iref" href="#rfc.xref.Part2.2">4.1</a></li>
+ </ul>
+ </li>
+ <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">3.1</a>, <a class="iref" href="#Part4"><b>9</b></a><ul class="ind">
+ <li class="indline1"><em>Section 5.6</em> <a class="iref" href="#rfc.xref.Part4.1">3.1</a></li>
+ </ul>
+ </li>
+ <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">2.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1</a>, <a class="iref" href="#Part5"><b>9</b></a><ul class="ind">
+ <li class="indline1"><em>Section 6.2</em> <a class="iref" href="#rfc.xref.Part5.2">3.1</a></li>
+ <li class="indline1"><em>Section A</em> <a class="iref" href="#rfc.xref.Part5.1">2.3.2</a></li>
+ </ul>
+ </li>
+ <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">3.1</a>, <a class="iref" href="#rfc.xref.Part6.2">4.1</a>, <a class="iref" href="#rfc.xref.Part6.3">5.7</a>, <a class="iref" href="#Part6"><b>9</b></a><ul class="ind">
+ <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part6.1">3.1</a></li>
+ </ul>
+ </li>
<li class="indline1">Public header <a class="iref" href="#rfc.iref.p.1"><b>C</b></a></li>
</ul>
</li>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org