Return-Path: Delivered-To: apmail-labs-commits-archive@locus.apache.org Received: (qmail 23531 invoked from network); 10 Dec 2007 21:51:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Dec 2007 21:51:58 -0000 Received: (qmail 87223 invoked by uid 500); 10 Dec 2007 21:51:46 -0000 Delivered-To: apmail-labs-commits-archive@labs.apache.org Received: (qmail 87088 invoked by uid 500); 10 Dec 2007 21:51:46 -0000 Mailing-List: contact commits-help@labs.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: labs@labs.apache.org Delivered-To: mailing list commits@labs.apache.org Received: (qmail 87076 invoked by uid 99); 10 Dec 2007 21:51:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Dec 2007 13:51:46 -0800 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.3] (HELO eris.apache.org) (140.211.11.3) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Dec 2007 21:51:26 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id 7119E1A983A; Mon, 10 Dec 2007 13:51:29 -0800 (PST) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: svn commit: r603063 [2/4] - /labs/webarch/trunk/http/draft-fielding-http/ Date: Mon, 10 Dec 2007 21:51:27 -0000 To: commits@labs.apache.org From: reschke@apache.org X-Mailer: svnmailer-1.0.8 Message-Id: <20071210215129.7119E1A983A@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org 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 Section A of [Part3].

2. Product Tokens

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.

- 
    request-header = Accept                   ; [Part 3]
-                   | Accept-Charset           ; [Part 3]
-                   | Accept-Encoding          ; [Part 3]
-                   | Accept-Language          ; [Part 3]
+      
    request-header = Accept                   ; [Part3], Section 5.1
+                   | Accept-Charset           ; [Part3], Section 5.2
+                   | Accept-Encoding          ; [Part3], Section 5.3
+                   | Accept-Language          ; [Part3], Section 5.4
                    | Authorization            ; [Part 7]
                    | Expect                   ; Section 10.2
                    | From                     ; Section 10.3
-                   | Host                     ; [Part 1]
+                   | Host                     ; [Part1], Section 8.4
                    | 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                  ; Section 10.6
-                   | TE                       ; [Part 1]
+                   | TE                       ; [Part1], Section 8.8
                    | User-Agent               ; Section 10.9
 
Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new
          or experimental header fields MAY be given the semantics of request-header fields if all parties in the communication recognize them to be request-header fields.
@@ -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.
       

-      
    response-header = Accept-Ranges           ; [Part 3]
+      
    response-header = Accept-Ranges           ; [Part5], Section 6.1
                     | Age                     ; [Part 6]
                     | ETag                    ; [Part 4]
                     | Location                ; Section 10.4
@@ -716,15 +716,14 @@
       
7. Entity

       
Request and Response messages MAY transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header
          fields and an entity-body, although some responses will only include the entity-headers. HTTP entity-body and entity-header
-         fields are defined in [Part 3].
+         fields are defined in [Part3].
       

-      
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.
+      
An entity-body is only present in a message when a message-body is present, as described in Section 4.3 of [Part1]. 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.
       

       
8. Method Definitions

       
The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed
-         to share the same semantics for separately extended clients and servers. The Host request-header field ([Part 1]) MUST accompany all HTTP/1.1 requests.
+         to share the same semantics for separately extended clients and servers. The Host request-header field (Section 8.4 of [Part1]) MUST accompany all HTTP/1.1 requests.
       

       
8.1 Safe and Idempotent Methods

       
8.1.1 Safe Methods

@@ -799,7 +798,8 @@
          reduce unnecessary network usage by allowing partially-retrieved entities to be completed without transferring data already
          held by the client.
       

-      
The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in [Part 6].

+      
The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in [Part6].
+      

       
See Section 12.2 for security considerations when used for forms.
       

       

@@ -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 Section 10.5). A TRACE request MUST NOT include an entity.
       

       
TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
-         or diagnostic information. The value of the Via header field ([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 (Section 8.9 of [Part1]) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
+         client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an
+         infinite loop.
       

       
If the request is valid, the response SHOULD contain the entire request message in the entity-body, with a Content-Type of "message/http". Responses to this method MUST NOT be cached.
       

@@ -922,14 +922,12 @@
       
9.1.1 100 Continue

       
The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been
          received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The
-         server MUST send a final response after the request has been completed. See [Part 1] for detailed discussion of the use and handling of
-         this status code.
+         server MUST send a final response after the request has been completed. See Section 7.2.3 of [Part1] for detailed discussion of the use and handling of this status code.
       

       

       

       
9.1.2 101 Switching Protocols

-      
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
+      
The server understands and is willing to comply with the client's request, via the Upgrade message header field (Section 6.4 of [Part5]), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
          by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
       

       
The protocol SHOULD 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 @@
       

       
9.2.7 206 Partial Content

       
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 [Part5].
       

       
9.3 Redirection 3xx

       
This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request.
@@ -1024,8 +1022,8 @@
       

       
9.3.1 300 Multiple Choices

       
The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent-driven
-         negotiation information ([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 (Section 4 of [Part3]) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that
+         location.
       

       
Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose
          the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending
@@ -1101,7 +1099,7 @@
             variant
          
       
-      
If the conditional GET used a strong cache validator (see [Part 6]), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
+      
If the conditional GET used a strong cache validator (see [Part6]), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
       

       
If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.
       

@@ -1333,7 +1331,7 @@
       
9.5.6 505 HTTP Version Not Supported

       
The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server
          is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
-         in [Part 1], other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server.
+         in Section 3.1 of [Part1], other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server.
       

       
10. Header Field Definitions

       
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 MUST be forwarded if the request is forwarded.
       

       
Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.

-      
See [Part 1] for the use of the 100 (continue) status.

+      
See Section 7.2.3 of [Part1] for the use of the 100 (continue) status.
+      

       

       

       
10.3 From

@@ -1412,9 +1411,8 @@
       
    Location: http://www.example.org/pub/WWW/People.html
 
 

       

-         
 Note: 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.
+         
 Note: The Content-Location header field (Section 5.7 of [Part3]) 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.
          

       

       

@@ -1466,7 +1464,7 @@
       
    Server         = "Server" ":" 1*( product | comment )
 
Example:

       
    Server: CERN/3.0 libwww/2.17
-
If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it MUST include a Via field (as described in [Part 1]). 
+
If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it MUST include a Via field (as described in Section 8.9 of [Part1]). 
       

       

          
 Note: Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
@@ -1538,12 +1536,32 @@
       
Based on an XML translation of RFC 2616 by Julian Reschke.

       
14. References
       

-                
+      

+            
+            
+         
+         
+            
+            
+         
+         
+            
+            
+         
+         
+            
+            
+         
+         
@@ -1785,6 +1803,31 @@
                
  • P
      
+                  
    • Part1  4, 4, 7, 8, 8.8, 9.1.1, 9.5.6, 10.2, 10.8, 14
        
+                        
      • Section 3.1  9.5.6
        • 
+                        
      • Section 4.3  7
        • 
+                        
      • Section 7.2.3  9.1.1, 10.2
        • 
+                        
      • Section 8.4  4, 8
        • 
+                        
      • Section 8.8  4
        • 
+                        
      • Section 8.9  8.8, 10.8
        • 
+                     
      
+                  
      • 
+                  
    • Part3  1, 4, 4, 4, 4, 7, 9.3.1, 10.4, 14
        
+                        
      • Section 4  9.3.1
        • 
+                        
      • Section 5.1  4
        • 
+                        
      • Section 5.2  4
        • 
+                        
      • Section 5.3  4
        • 
+                        
      • Section 5.4  4
        • 
+                        
      • Section 5.7  10.4
        • 
+                        
      • Section A  1
        • 
+                     
      
+                  
      • 
+                  
    • Part5  6, 9.1.2, 9.2.7, 14
        
+                        
      • Section 6.1  6
        • 
+                        
      • Section 6.4  9.1.2
        • 
+                     
      
+                  
      • 
+                  
    • Part6  8.3, 9.3.5, 14
      • 
                   
    • PATCH method  A
      • 
                   
    • POST method  3, 8.5
      • 
                   
    • PUT method  3, 8.6
      • 

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 @@
   SHOULD">
   SHOULD NOT">
   
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
+  
+  
+  ">
+  ">
+  ">
+  ">
+  ">
+  ">
+  ">
+  ">
+  ">
+  ">
+  ">
+  ">
+  ">
+  ">
+  ">
+  ">
+  ">
+  ">
   
   
   
-  
+  ">
   
   
   
-  
+  ">
   
   
   
@@ -46,13 +48,13 @@
   
   
   
-  
-  
+  ">
+  ">
   
-  
+  ">
   
   
-  
+  ">
 ]>
 
 
@@ -175,7 +177,7 @@
     
   
 
-  
+  
 
 
 
@@ -2075,6 +2077,466 @@
 
 
 
+
+
+  
+    HTTP/1.1, part 1: URIs, Connections, and Message Parsing
+  
+    
+      Day Software
+      
      
+        
+          23 Corporate Plaza DR, Suite 280
+          Newport Beach
+          CA
+          92660
+          USA
+        
+        +1-949-706-5300
+        +1-949-706-5305
+        fielding@gbiv.com
+        http://roy.gbiv.com/
+      
      
+          
+  
+    
+      One Laptop per Child
+      
      
+        
+          21 Oak Knoll Road
+          Carlisle
+          MA
+          01741
+          USA
+        
+        jg@laptop.org
+        http://www.laptop.org/
+      
      
+          
+    
+    
+      Hewlett-Packard Company
+      
      
+        
+          HP Labs, Large Scale Systems Group
+          1501 Page Mill Road, MS 1177
+          Palo Alto
+          CA
+          94304
+          USA
+        
+        JeffMogul@acm.org
+      
      
+          
+  
+    
+      Microsoft Corporation
+      
      
+        
+          1 Microsoft Way
+          Redmond
+          WA
+          98052
+          USA
+        
+        henrikn@microsoft.com
+      
      
+          
+  
+    
+      Adobe Systems, Incorporated
+      
      
+        
+          345 Park Ave
+          San Jose
+          CA
+          95110
+          USA
+        
+        LMM@acm.org
+        http://larry.masinter.net/
+      
      
+          
+    
+    
+      Microsoft Corporation
+      
      
+        
+          1 Microsoft Way
+          Redmond
+          WA
+          98052
+        
+        paulle@microsoft.com
+      
      
+          
+     
+    
+      World Wide Web Consortium
+      
      
+        
+          MIT Laboratory for Computer Science
+          545 Technology Square
+          Cambridge
+          MA
+          02139
+          USA
+        
+        +1 (617) 258 8682
+        timbl@w3.org
+      
      
+          
+  
+    
+        
+  
+  
+      
+
+
+  
+    HTTP/1.1, part 3: Message Payload and Content Negotiation
+  
+    
+      Day Software
+      
      
+        
+          23 Corporate Plaza DR, Suite 280
+          Newport Beach
+          CA
+          92660
+          USA
+        
+        +1-949-706-5300
+        +1-949-706-5305
+        fielding@gbiv.com
+        http://roy.gbiv.com/
+      
      
+          
+  
+    
+      One Laptop per Child
+      
      
+        
+          21 Oak Knoll Road
+          Carlisle
+          MA
+          01741
+          USA
+        
+        jg@laptop.org
+        http://www.laptop.org/
+      
      
+          
+    
+    
+      Hewlett-Packard Company
+      
      
+        
+          HP Labs, Large Scale Systems Group
+          1501 Page Mill Road, MS 1177
+          Palo Alto
+          CA
+          94304
+          USA
+        
+        JeffMogul@acm.org
+      
      
+          
+  
+    
+      Microsoft Corporation
+      
      
+        
+          1 Microsoft Way
+          Redmond
+          WA
+          98052
+          USA
+        
+        henrikn@microsoft.com
+      
      
+          
+  
+    
+      Adobe Systems, Incorporated
+      
      
+        
+          345 Park Ave
+          San Jose
+          CA
+          95110
+          USA
+        
+        LMM@acm.org
+        http://larry.masinter.net/
+      
      
+          
+    
+    
+      Microsoft Corporation
+      
      
+        
+          1 Microsoft Way
+          Redmond
+          WA
+          98052
+        
+        paulle@microsoft.com
+      
      
+          
+     
+    
+      World Wide Web Consortium
+      
      
+        
+          MIT Laboratory for Computer Science
+          545 Technology Square
+          Cambridge
+          MA
+          02139
+          USA
+        
+        +1 (617) 258 8682
+        timbl@w3.org
+      
      
+          
+  
+    
+        
+  
+  
+      
+
+
+  
+    HTTP/1.1, part 5: Range Requests and Partial Responses
+  
+    
+      Day Software
+      
      
+        
+          23 Corporate Plaza DR, Suite 280
+          Newport Beach
+          CA
+          92660
+          USA
+        
+        +1-949-706-5300
+        +1-949-706-5305
+        fielding@gbiv.com
+        http://roy.gbiv.com/
+      
      
+          
+  
+    
+      One Laptop per Child
+      
      
+        
+          21 Oak Knoll Road
+          Carlisle
+          MA
+          01741
+          USA
+        
+        jg@laptop.org
+        http://www.laptop.org/
+      
      
+          
+    
+    
+      Hewlett-Packard Company
+      
      
+        
+          HP Labs, Large Scale Systems Group
+          1501 Page Mill Road, MS 1177
+          Palo Alto
+          CA
+          94304
+          USA
+        
+        JeffMogul@acm.org
+      
      
+          
+  
+    
+      Microsoft Corporation
+      
      
+        
+          1 Microsoft Way
+          Redmond
+          WA
+          98052
+          USA
+        
+        henrikn@microsoft.com
+      
      
+          
+  
+    
+      Adobe Systems, Incorporated
+      
      
+        
+          345 Park Ave
+          San Jose
+          CA
+          95110
+          USA
+        
+        LMM@acm.org
+        http://larry.masinter.net/
+      
      
+          
+    
+    
+      Microsoft Corporation
+      
      
+        
+          1 Microsoft Way
+          Redmond
+          WA
+          98052
+        
+        paulle@microsoft.com
+      
      
+          
+     
+    
+      World Wide Web Consortium
+      
      
+        
+          MIT Laboratory for Computer Science
+          545 Technology Square
+          Cambridge
+          MA
+          02139
+          USA
+        
+        +1 (617) 258 8682
+        timbl@w3.org
+      
      
+          
+  
+    
+        
+  
+  
+      
+
+
+  
+    HTTP/1.1, part 6: Caching
+  
+    
+      Day Software
+      
      
+        
+          23 Corporate Plaza DR, Suite 280
+          Newport Beach
+          CA
+          92660
+          USA
+        
+        +1-949-706-5300
+        +1-949-706-5305
+        fielding@gbiv.com
+        http://roy.gbiv.com/
+      
      
+          
+  
+    
+      One Laptop per Child
+      
      
+        
+          21 Oak Knoll Road
+          Carlisle
+          MA
+          01741
+          USA
+        
+        jg@laptop.org
+        http://www.laptop.org/
+      
      
+          
+    
+    
+      Hewlett-Packard Company
+      
      
+        
+          HP Labs, Large Scale Systems Group
+          1501 Page Mill Road, MS 1177
+          Palo Alto
+          CA
+          94304
+          USA
+        
+        JeffMogul@acm.org
+      
      
+          
+  
+    
+      Microsoft Corporation
+      
      
+        
+          1 Microsoft Way
+          Redmond
+          WA
+          98052
+          USA
+        
+        henrikn@microsoft.com
+      
      
+          
+  
+    
+      Adobe Systems, Incorporated
+      
      
+        
+          345 Park Ave
+          San Jose
+          CA
+          95110
+          USA
+        
+        LMM@acm.org
+        http://larry.masinter.net/
+      
      
+          
+    
+    
+      Microsoft Corporation
+      
      
+        
+          1 Microsoft Way
+          Redmond
+          WA
+          98052
+        
+        paulle@microsoft.com
+      
      
+          
+     
+    
+      World Wide Web Consortium
+      
      
+        
+          MIT Laboratory for Computer Science
+          545 Technology Square
+          Cambridge
+          MA
+          02139
+          USA
+        
+        +1 (617) 258 8682
+        timbl@w3.org
+      
      
+          
+  
+    
+        
+  
+  
+      
 
 
 

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.
       
      
       
      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 SHOULD 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 (Section A of [Part5]) when it appears in a 206 (Partial Content) response. In all other cases, an HTTP user agent SHOULD 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.
       
      
       
      In general, an HTTP user agent SHOULD follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. If an application receives
@@ -709,16 +708,16 @@
       
      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 OPTIONAL; some might be REQUIRED by portions of this specification.
       
      
-      
          entity-header  = Allow                    ; [Part 2]
+      
          entity-header  = Allow                    ; [Part2], Section 10.1
                    | Content-Encoding         ; Section 5.5
                    | Content-Language         ; Section 5.6
-                   | Content-Length           ; [Part 1]
+                   | Content-Length           ; [Part1], Section 8.2
                    | Content-Location         ; Section 5.7
                    | Content-MD5              ; Section 5.8
-                   | Content-Range            ; [Part 5]
+                   | Content-Range            ; [Part5], Section 6.2
                    | Content-Type             ; Section 5.9
-                   | Expires                  ; [Part 6]
-                   | Last-Modified            ; [Part 4]
+                   | Expires                  ; [Part6], Section 3.3
+                   | Last-Modified            ; [Part4], Section 5.6
                    | extension-header
 
     extension-header = message-header
@@ -728,9 +727,8 @@
       
      3.2 Entity Body
      
       
      The entity-body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.
      
       
          entity-body    = *OCTET
-
      An entity-body is only present in a message when a message-body is present, as described in [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.
+
      An entity-body is only present in a message when a message-body is present, as described in Section 4.3 of [Part1]. 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.
       
      
       
      3.2.1 Type
      
       
      When an entity-body is included with a message, the data type of that body is determined via the header fields Content-Type
@@ -746,8 +744,7 @@
          resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".
       
      
       
      3.2.2 Entity Length
      
-      
      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.
+      
      The entity-length of a message is the length of the message-body before any transfer-codings have been applied. Section 4.4 of [Part1] defines how the transfer-length of a message-body is determined.
       
      
       
      4. Content Negotiation
      
       
      Most HTTP responses include an entity which contains information for interpretation by a human user. Naturally, it is desirable
@@ -792,11 +789,10 @@
          
    • It may limit a public cache's ability to use the same response for multiple user's requests.
      • 
       
       
      HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent
-         capabilities and user preferences: Accept (Section 5.1), Accept-Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language (Section 5.4), and User-Agent ([Part 2]). However, an origin server is not limited to these dimensions and MAY vary the response based on any aspect of the request, including information outside the request-header fields or within extension
+         capabilities and user preferences: Accept (Section 5.1), Accept-Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language (Section 5.4), and User-Agent (Section 10.9 of [Part2]). However, an origin server is not limited to these dimensions and MAY vary the response based on any aspect of the request, including information outside the request-header field
 s or within extension
          header fields not defined by this specification.
       
      
-      
      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.
+      
      The Vary header field [Part6] can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.
       
      
       
      4.2 Agent-driven Negotiation
      
       
      With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving
@@ -1074,7 +1070,7 @@
       
      
       
      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 [Part6].
       
      
       
      If the Content-Location is a relative URI, the relative URI is interpreted relative to the Request-URI.
      
       
      The meaning of the Content-Location header in PUT or POST requests is undefined; servers are free to ignore it in those cases.
      
@@ -1162,7 +1158,32 @@
       
      Based on an XML translation of RFC 2616 by Julian Reschke.
      
       
      9. References
       
      
-      
    •                   
          
    
             [Luo1998]
             Luotonen, A., “Tunneling TCP based protocols through Web proxy servers”,  Work in Progress.
          
    
          
    [Part1]Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing”, Internet-Draft draft-fielding-p1-messaging-latest (work in progress), December 2007.
+            
    [Part3]Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “HTTP/1.1, part 3: Message Payload and Content Negotiation”, Internet-Draft draft-fielding-p3-payload-latest (work in progress), December 2007.
+            
    [Part5]Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “HTTP/1.1, part 5: Range Requests and Partial Responses”, Internet-Draft draft-fielding-p5-range-latest (work in progress), December 2007.
+            
    [Part6]Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “HTTP/1.1, part 6: Caching”, Internet-Draft draft-fielding-p6-cache-latest (work in progress), December 2007.
+            
    
             [RFC1123]
             Braden, R., “Requirements for Internet Hosts - Application and Support”, STD 3, RFC 1123, October 1989.
             
             
             
                                        
+      
                                                  
+         
+            
+            
+         
+         
+            
+            
+         
+         
+            
+            
+         
+         
+            
+            
+         
+         
+            
+            
+         
    [Part1]Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing”, Internet-Draft draft-fielding-p1-messaging-latest (work in progress), December 2007.
+            
    [Part2]Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “HTTP/1.1, part 2: Message Semantics”, Internet-Draft draft-fielding-p2-semantics-latest (work in progress), December 2007.
+            
    [Part4]Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “HTTP/1.1, part 4: Conditional Requests”, Internet-Draft draft-fielding-p4-conditional-latest (work in progress), December 2007.
+            
    [Part5]Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “HTTP/1.1, part 5: Range Requests and Partial Responses”, Internet-Draft draft-fielding-p5-range-latest (work in progress), December 2007.
+            
    [Part6]Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “HTTP/1.1, part 6: Caching”, Internet-Draft draft-fielding-p6-cache-latest (work in progress), December 2007.
+            
    
          
    
             [RFC1766]
             Alvestrand, H., “Tags for the Identification of Languages”, RFC 1766, March 1995.
@@ -1311,7 +1332,7 @@
          the destination protocol.
       
    
       
    A.5 Introduction of Transfer-Encoding
    
-      
    HTTP/1.1 introduces the Transfer-Encoding header field ([Part 1]). Proxies/gateways MUST remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
+      
    HTTP/1.1 introduces the Transfer-Encoding header field (Section 8.7 of [Part1]). Proxies/gateways MUST remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
       
    
       
    A.6 MHTML and Line Length Limitations
    
       
    HTTP implementations which share code with MHTML [RFC2110] implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not
@@ -1497,6 +1518,31 @@
                
             
             
  • P
             
    • 



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