labs-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From resc...@apache.org
Subject svn commit: r603222 [1/2] - /labs/webarch/trunk/http/draft-fielding-http/
Date Tue, 11 Dec 2007 12:19:57 GMT
Author: reschke
Date: Tue Dec 11 04:19:55 2007
New Revision: 603222

URL: http://svn.apache.org/viewvc?rev=603222&view=rev
Log:
make cross document links actually link to sibling documents

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

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=603222&r1=603221&r2=603222&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html Tue Dec 11 04:19:55 2007
@@ -646,19 +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 <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>.
+            entity-header fields and content in the form of an entity-body, as described in <a href="p3-payload.html#entity" 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 <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>An entity included with a response that is subject to content negotiation, as described in <a href="p3-payload.html#content.negotiation" 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 <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>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="p3-payload.html#content.negotiation" 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>  
@@ -732,7 +732,7 @@
       </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 <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
+            The rules for determining the cacheability of HTTP responses are defined in <a href="p6-cache.html#caching" 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>
@@ -753,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 <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>.
+         entity-body content. The relationship between HTTP and MIME is described in <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" 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
@@ -789,7 +789,7 @@
        UA -----v----- A -----v----- B - - - - - - C - - - - - - O
           &lt;--------- 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 <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>.
+         behavior. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching" 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,
@@ -976,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 <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 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="p2-semantics.html#status.414" 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">
@@ -1156,7 +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>&nbsp;<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&nbsp;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
+      <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&nbsp;4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" 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="p2-semantics.html#response.header.fields" 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="p3-payload.html#entity.header.fields" 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.
@@ -1192,7 +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 (<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,
+         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="p2-semantics.html#method" 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
@@ -1252,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            ; <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>
+      <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="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a>
                    | Connection               ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>
                    | Date                     ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;8.3</a>
-                   | 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>
+                   | Pragma                   ; <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>
                    | Trailer                  ; <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;8.6</a>
                    | Transfer-Encoding        ; <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;8.7</a>
                    | Upgrade                  ; <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;8.8</a>
                    | Via                      ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.9</a>
-                   | 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>
+                   | Warning                  ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" 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.
@@ -1271,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&nbsp;5.1</a>
                      *(( general-header        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>
-                      | 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>
+                      | request-header         ; <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" 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="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
                      CRLF
                      [ message-body ]          ; <a href="#message.body" title="Message Body">Section&nbsp;4.3</a>
 </pre><h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="request-line" href="#request-line">Request-Line</a></h2>
@@ -1303,7 +1303,7 @@
       <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 (<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 id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" 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&nbsp;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
@@ -1349,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&nbsp;6.1</a>
                     *(( general-header        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>
-                     | 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>
+                     | response-header        ; <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" 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="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
                     CRLF
                     [ message-body ]          ; <a href="#message.body" title="Message Body">Section&nbsp;4.3</a>
 </pre><h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="status-line" href="#status-line">Status-Line</a></h2>
@@ -1361,7 +1361,7 @@
       <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>&nbsp;<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 <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
+         are fully defined in <a href="p2-semantics.html#status.codes" 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.
@@ -1430,7 +1430,7 @@
       </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 <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
+      <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="p2-semantics.html#idempotent.methods" 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>&nbsp;<a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3>
@@ -1455,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 <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
+         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" 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.
@@ -1473,16 +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&nbsp;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>&nbsp;<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 <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
+      <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see <a href="p2-semantics.html#status.100" 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 (<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>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="p2-semantics.html#header.expect" 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 (<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>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" 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:
@@ -1526,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 <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>).
+            of 1xx responses (see <a href="p2-semantics.html#status.1xx" 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>&nbsp;<a id="connection.premature" href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></h3>
@@ -1692,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 <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.")
+               is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" 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>

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=603222&r1=603221&r2=603222&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml Tue Dec 11 04:19:55 2007
@@ -2919,7 +2919,7 @@
     <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"/>
+  <x:source href="p2-semantics.xml" basename="p2-semantics"/>
 </reference>
 
 <reference anchor="Part3">
@@ -2978,7 +2978,7 @@
     <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"/>
+  <x:source href="p3-payload.xml" basename="p3-payload"/>
 </reference>
 
 <reference anchor="Part6">
@@ -3037,7 +3037,7 @@
     <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"/>
+  <x:source href="p6-cache.xml" basename="p6-cache"/>
 </reference>
 
 <reference anchor="RFC1436">

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=603222&r1=603221&r2=603222&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html Tue Dec 11 04:19:55 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 <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>.
+         entity-body content. The relationship between HTTP and MIME is described in <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" 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>&nbsp;<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                   ; <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>
+      <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="p3-payload.html#header.accept" 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="p3-payload.html#header.accept-charset" 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="p3-payload.html#header.accept-encoding" 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="p3-payload.html#header.accept-language" title="Accept-Language">Section 5.4</a>
                    | Authorization            ; [Part 7]
                    | Expect                   ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section&nbsp;10.2</a>
                    | From                     ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section&nbsp;10.3</a>
-                   | 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>
+                   | 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="p1-messaging.html#header.host" 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&nbsp;10.6</a>
-                   | 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>
+                   | 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="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.8</a>
                    | User-Agent               ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section&nbsp;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           ; <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>
+      <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="p5-range.html#header.accept-ranges" 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&nbsp;10.4</a>
@@ -718,12 +718,12 @@
          fields and an entity-body, although some responses will only include the entity-headers. HTTP entity-body and entity-header
          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 <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
+      <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="p1-messaging.html#message.body" 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>&nbsp;<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 (<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.
+         to share the same semantics for separately extended clients and servers. The Host request-header field (<a href="p1-messaging.html#header.host" 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>&nbsp;<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>&nbsp;<a id="safe.methods" href="#safe.methods">Safe Methods</a></h3>
@@ -889,7 +889,7 @@
          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&nbsp;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 (<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
+         or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" 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>
@@ -922,12 +922,12 @@
       <h3 id="rfc.section.9.1.1"><a href="#rfc.section.9.1.1">9.1.1</a>&nbsp;<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 <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.
+         server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" 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>&nbsp;<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 (<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
+      <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="p5-range.html#header.range" 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
@@ -1022,7 +1022,7 @@
       <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>&nbsp;<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 (<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
+         negotiation information (<a href="p3-payload.html#content.negotiation" 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
@@ -1331,7 +1331,7 @@
       <h3 id="rfc.section.9.5.6"><a href="#rfc.section.9.5.6">9.5.6</a>&nbsp;<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 <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.
+         in <a href="p1-messaging.html#http.version" 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>&nbsp;<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
@@ -1377,7 +1377,7 @@
          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 <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 id="rfc.section.10.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" 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>
@@ -1411,7 +1411,7 @@
       <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 (<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.
+         <dd> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" 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>
@@ -1464,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 <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>). 
+</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="p1-messaging.html#header.via" 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

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=603222&r1=603221&r2=603222&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml Tue Dec 11 04:19:55 2007
@@ -2134,7 +2134,7 @@
     <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"/>
+  <x:source href="p1-messaging.xml" basename="p1-messaging"/>
 </reference>
 
 <reference anchor="Part3">
@@ -2193,7 +2193,7 @@
     <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"/>
+  <x:source href="p3-payload.xml" basename="p3-payload"/>
 </reference>
 
 <reference anchor="Part5">
@@ -2252,7 +2252,7 @@
     <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"/>
+  <x:source href="p5-range.xml" basename="p5-range"/>
 </reference>
 
 <reference anchor="Part6">
@@ -2311,7 +2311,7 @@
     <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"/>
+  <x:source href="p6-cache.xml" basename="p6-cache"/>
 </reference>
 
 <reference anchor="RFC1123">

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=603222&r1=603221&r2=603222&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p3-payload.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p3-payload.html Tue Dec 11 04:19:55 2007
@@ -660,7 +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 (<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
+         is the "multipart/byteranges" type (<a href="p5-range.html#internet.media.type.multipart.byteranges" 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
@@ -708,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                    ; <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>
+      <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="p2-semantics.html#header.allow" title="Allow">Section 10.1</a>
                    | Content-Encoding         ; <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;5.5</a>
                    | Content-Language         ; <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;5.6</a>
-                   | 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-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="p1-messaging.html#header.content-length" 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&nbsp;5.7</a>
                    | Content-MD5              ; <a href="#header.content-md5" id="rfc.xref.header.content-md5.1" title="Content-MD5">Section&nbsp;5.8</a>
-                   | 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-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="p5-range.html#header.content-range" 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&nbsp;5.9</a>
-                   | 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>
+                   | Expires                  ; <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.expires" 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="p4-conditional.html#header.last-modified" title="Last-Modified">Section 5.6</a>
                    | extension-header
 
     extension-header = message-header
@@ -727,7 +727,7 @@
       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<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 <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
+</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="p1-messaging.html#message.body" 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>&nbsp;<a id="type" href="#type">Type</a></h3>
@@ -744,7 +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>&nbsp;<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. <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 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="p1-messaging.html#message.length" 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>&nbsp;<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
@@ -789,7 +789,7 @@
          <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&nbsp;5.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;5.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;5.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;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
+         capabilities and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;5.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;5.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;5.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;5.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" 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 fields or within extension
          header fields not defined by this specification.
       </p>
       <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.
@@ -1332,7 +1332,7 @@
          the destination protocol.
       </p>
       <h2 id="rfc.section.A.5"><a href="#rfc.section.A.5">A.5</a>&nbsp;<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 (<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 id="rfc.section.A.5.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" 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>&nbsp;<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

Modified: labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml?rev=603222&r1=603221&r2=603222&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml Tue Dec 11 04:19:55 2007
@@ -1444,7 +1444,7 @@
     <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"/>
+  <x:source href="p1-messaging.xml" basename="p1-messaging"/>
 </reference>
 
 <reference anchor="Part2">
@@ -1503,7 +1503,7 @@
     <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"/>
+  <x:source href="p2-semantics.xml" basename="p2-semantics"/>
 </reference>
 
 <reference anchor="Part4">
@@ -1562,7 +1562,7 @@
     <date month="&ID-MONTH;" year="&ID-YEAR;"/>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-fielding-p4-conditional-&ID-VERSION;"/>
-  <x:source href="p4-conditional.xml"/>
+  <x:source href="p4-conditional.xml" basename="p4-conditional"/>
 </reference>
 
 <reference anchor="Part5">
@@ -1621,7 +1621,7 @@
     <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"/>
+  <x:source href="p5-range.xml" basename="p5-range"/>
 </reference>
 
 <reference anchor="Part6">
@@ -1680,7 +1680,7 @@
     <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"/>
+  <x:source href="p6-cache.xml" basename="p6-cache"/>
 </reference>
 
 <reference anchor="RFC1766">

Modified: labs/webarch/trunk/http/draft-fielding-http/p4-conditional.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p4-conditional.html?rev=603222&r1=603221&r2=603222&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p4-conditional.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p4-conditional.html Tue Dec 11 04:19:55 2007
@@ -482,7 +482,7 @@
       </p>
       <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="entity.tags" href="#entity.tags">Entity Tags</a></h1>
       <p id="rfc.section.2.p.1">Entity tags are used for comparing two or more entities from the same requested resource. HTTP/1.1 uses entity tags in the
-         ETag (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section&nbsp;5.1</a>), If-Match (<a href="#header.if-match" id="rfc.xref.header.if-match.1" title="If-Match">Section&nbsp;5.2</a>), If-None-Match (<a href="#header.if-none-match" id="rfc.xref.header.if-none-match.1" title="If-None-Match">Section&nbsp;5.4</a>), and If-Range (<a href="http://tools.ietf.org/html/draft-fielding-p5-range-latest" title="If-Range">Section 6.3</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>) header fields. The definition of how they are used and compared as cache validators is in <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;3</a>. An entity tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
+         ETag (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section&nbsp;5.1</a>), If-Match (<a href="#header.if-match" id="rfc.xref.header.if-match.1" title="If-Match">Section&nbsp;5.2</a>), If-None-Match (<a href="#header.if-none-match" id="rfc.xref.header.if-none-match.1" title="If-None-Match">Section&nbsp;5.4</a>), and If-Range (<a href="p5-range.html#header.if-range" title="If-Range">Section 6.3</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>) header fields. The definition of how they are used and compared as cache validators is in <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;3</a>. An entity tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
       </p>
       <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>   entity-tag = [ weak ] opaque-tag
    weak       = "W/"
@@ -642,7 +642,7 @@
       <div id="rfc.iref.h.1"></div>
       <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="header.etag" href="#header.etag">ETag</a></h2>
       <p id="rfc.section.5.1.p.1">The ETag response-header field provides the current value of the entity tag for the requested variant. The headers used with
-         entity tags are described in sections <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">5.2</a>, <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">5.4</a> and <a href="http://tools.ietf.org/html/draft-fielding-p5-range-latest" title="If-Range">Section 6.3</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>. The entity tag <em class="bcp14">MAY</em> be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;3</a>).
+         entity tags are described in sections <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">5.2</a>, <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">5.4</a> and <a href="p5-range.html#header.if-range" title="If-Range">Section 6.3</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>. The entity tag <em class="bcp14">MAY</em> be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;3</a>).
       </p>
       <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.4"></span>    ETag = "ETag" ":" entity-tag
 </pre><div id="rfc.figure.u.3"></div>
@@ -671,7 +671,7 @@
       <p id="rfc.section.5.2.p.6">If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status, then the If-Match
          header <em class="bcp14">MUST</em> be ignored.
       </p>
-      <p id="rfc.section.5.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="http://tools.ietf.org/html/draft-fielding-p6-cache-latest" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.
+      <p id="rfc.section.5.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.
       </p>
       <p id="rfc.section.5.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource.
          This allows the user to indicate that they do not wish the request to be successful if the resource has been changed without
@@ -707,7 +707,7 @@
       </ol>
       <p id="rfc.section.5.3.p.6">The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. </p>
       <dl class="empty">
-         <dd> <b>Note:</b> The Range request-header field modifies the meaning of If-Modified-Since; see <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.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> for full details.
+         <dd> <b>Note:</b> The Range request-header field modifies the meaning of If-Modified-Since; see <a href="p5-range.html#header.range" title="Range">Section 6.4</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> for full details.
          </dd>
          <dd> <b>Note:</b> If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client.
          </dd>
@@ -752,7 +752,7 @@
       <p id="rfc.section.5.4.p.7">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status, then the
          If-None-Match header <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity Tags and Last-Modified Dates">Section&nbsp;4</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
       </p>
-      <p id="rfc.section.5.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="http://tools.ietf.org/html/draft-fielding-p6-cache-latest" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.
+      <p id="rfc.section.5.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.
       </p>
       <p id="rfc.section.5.4.p.9">Examples:</p>
       <div id="rfc.figure.u.9"></div><pre class="text">    If-None-Match: "xyzzy"

Modified: labs/webarch/trunk/http/draft-fielding-http/p4-conditional.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p4-conditional.xml?rev=603222&r1=603221&r2=603222&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p4-conditional.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p4-conditional.xml Tue Dec 11 04:19:55 2007
@@ -859,7 +859,7 @@
     <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"/>
+  <x:source href="p1-messaging.xml" basename="p1-messaging"/>
 </reference>
 
 <reference anchor="Part5">
@@ -918,7 +918,7 @@
     <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"/>
+  <x:source href="p5-range.xml" basename="p5-range"/>
 </reference>
 
 <reference anchor="Part6">
@@ -977,7 +977,7 @@
     <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"/>
+  <x:source href="p6-cache.xml" basename="p6-cache"/>
 </reference>
 
 

Modified: labs/webarch/trunk/http/draft-fielding-http/p5-range.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p5-range.html?rev=603222&r1=603221&r2=603222&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p5-range.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p5-range.html Tue Dec 11 04:19:55 2007
@@ -539,7 +539,7 @@
       </p>
       <ul>
          <li>Both the incoming response and the cache entry have a cache validator.</li>
-         <li>The two cache validators match using the strong comparison function (see <a href="http://tools.ietf.org/html/draft-fielding-p4-conditional-latest" title="Weak and Strong Validators">Section 3</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
+         <li>The two cache validators match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 3</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
          </li>
       </ul>
       <p id="rfc.section.5.p.3">If either requirement is not met, the cache <em class="bcp14">MUST</em> use only the most recent partial response (based on the Date values transmitted with every response, and using the incoming

Modified: labs/webarch/trunk/http/draft-fielding-http/p5-range.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p5-range.xml?rev=603222&r1=603221&r2=603222&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p5-range.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p5-range.xml Tue Dec 11 04:19:55 2007
@@ -725,7 +725,7 @@
     <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"/>
+  <x:source href="p1-messaging.xml" basename="p1-messaging"/>
 </reference>
 
 <reference anchor="Part4">
@@ -784,7 +784,7 @@
     <date month="&ID-MONTH;" year="&ID-YEAR;"/>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-fielding-p4-conditional-&ID-VERSION;"/>
-  <x:source href="p4-conditional.xml"/>
+  <x:source href="p4-conditional.xml" basename="p4-conditional"/>
 </reference>
 
 <reference anchor="RFC2046">



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org


Mime
View raw message