Return-Path: Delivered-To: apmail-labs-commits-archive@locus.apache.org Received: (qmail 23757 invoked from network); 10 Dec 2007 21:51:59 -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:59 -0000 Received: (qmail 87415 invoked by uid 500); 10 Dec 2007 21:51:48 -0000 Delivered-To: apmail-labs-commits-archive@labs.apache.org Received: (qmail 87297 invoked by uid 500); 10 Dec 2007 21:51:47 -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 87286 invoked by uid 99); 10 Dec 2007 21:51:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Dec 2007 13:51:47 -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:52 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id A7A931A9846; 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 [4/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.A7A931A9846@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Modified: labs/webarch/trunk/http/draft-fielding-http/p6-cache.html URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p6-cache.html?rev=603063&r1=603062&r2=603063&view=diff ============================================================================== --- labs/webarch/trunk/http/draft-fielding-http/p6-cache.html (original) +++ labs/webarch/trunk/http/draft-fielding-http/p6-cache.html Mon Dec 10 13:51:25 2007 @@ -782,8 +782,7 @@ Hosts that use HTTP, but especially hosts running origin servers and caches, SHOULD use NTP [RFC1305] or some similar protocol to synchronize their clocks to a globally accurate time standard.

HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response - was generated (see [Part 1]). We use the term "date_value" to denote the value of the Date header, in a form appropriate for - arithmetic operations. + was generated (see Section 8.3 of [Part1]). We use the term "date_value" to denote the value of the Date header, in a form appropriate for arithmetic operations.

HTTP/1.1 uses the Age response-header to convey the estimated age of the response message when obtained from a cache. The Age field value is the cache's estimate of the amount of time since the response was generated or revalidated by the origin @@ -905,8 +904,7 @@ agent or proxy cache) makes a conditional request for a resource for which it has a cache entry, it includes the associated validator in the request.

The server then checks that validator against the current validator for the entity, and, if they match (see [Part 4]), it - responds with a special status code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it returns a full response +

The server then checks that validator against the current validator for the entity, and, if they match (see Section 3 of [Part4]), it responds with a special status code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it returns a full response (including entity-body). Thus, we avoid transmitting the full response if the validator matches, and we avoid an extra round trip if it does not match.

@@ -932,7 +930,8 @@ values is not sufficient, or where the origin server wishes to avoid certain paradoxes that might arise from the use of modification dates.

Entity Tags are described in [Part 4].

Entity Tags are described in Section 2 of [Part4]. +

2.3.3 Non-validating Conditionals

The principle behind entity tags is that only the service author knows the semantics of a resource well enough to select an appropriate cache validation mechanism, and the specification of any validator comparison function more complex than byte-equality @@ -953,8 +952,8 @@ or privacy considerations. Certain cache-control directives are therefore provided so that the server can indicate that certain resource entities, or portions thereof, are not to be cached regardless of other considerations.

Note that [Part 7] normally prevents a shared cache from saving and returning a response to a previous request if that request - included an Authorization header. +

Note that Section 2.1 of [Part7] normally prevents a shared cache from saving and returning a response to a previous request if that request included an Authorization + header.

A response received with a status code of 200, 203, 206, 300, 301 or 410 MAY be stored by a cache and used in reply to a subsequent request, subject to the expiration mechanism, unless a cache-control directive prohibits caching. However, a cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial Content) responses. @@ -989,7 +988,7 @@

Upgrade

All other headers defined by HTTP/1.1 are end-to-end headers.

Other hop-by-hop headers MUST be listed in a Connection header ([Part 1]). +

Other hop-by-hop headers MUST be listed in a Connection header (Section 8.1 of [Part1]).

2.5.2 Non-modifiable Headers

Some features of the HTTP/1.1 protocol, such as Digest Authentication, depend on the value of certain end-to-end headers. @@ -1024,7 +1023,7 @@ are introduced in later versions of HTTP. Such authentication mechanisms MAY rely on the values of header fields not listed here. -

The Content-Length field of a request or response is added or deleted according to the rules in [Part 1]. A transparent proxy MUST preserve the entity-length ([Part 3]) of the entity-body, although it MAY change the transfer-length ([Part 1]). +

The Content-Length field of a request or response is added or deleted according to the rules in Section 4.4 of [Part1]. A transparent proxy MUST preserve the entity-length (Section 3.2.2 of [Part3]) of the entity-body, although it MAY change the transfer-length (Section 4.4 of [Part1]).

2.5.3 Combining Headers

When a cache makes a validating request to a server, and the server provides a 304 (Not Modified) response or a 206 (Partial @@ -1032,7 +1031,7 @@

If the status code is 304 (Not Modified), the cache uses the entity-body stored in the cache entry as the entity-body of this outgoing response. If the status code is 206 (Partial Content) and the ETag or Last-Modified headers match exactly, the cache MAY combine the contents stored in the cache entry with the new contents received in the response and use the result as the entity-body - of this outgoing response, (see [Part 5]). + of this outgoing response, (see Section 5 of [Part5]).

The end-to-end headers stored in the cache entry are used for the constructed response, except that

2.6 Caching Negotiated Responses

Use of server-driven content negotiation ([Part 3]), as indicated by the presence of a Vary header field in a response, alters - the conditions and procedure by which a cache can use the response for subsequent requests. See Section 3.5 for use of the Vary header field by servers. +

Use of server-driven content negotiation (Section 4.1 of [Part3]), as indicated by the presence of a Vary header field in a response, alters the conditions and procedure by which a cache + can use the response for subsequent requests. See Section 3.5 for use of the Vary header field by servers.

A server SHOULD use the Vary header field to inform a cache of what request-header fields were used to select among multiple representations of a cacheable response subject to server-driven negotiation. The set of header fields named by the Vary field value is known @@ -1072,7 +1071,7 @@

The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first request can be transformed to the selecting request-headers in the second request by adding or removing linear white space (LWS) at places where this is allowed by the corresponding BNF, and/or combining multiple message-header fields with the same - field name following the rules about message headers in [Part 1]. + field name following the rules about message headers in Section 4.2 of [Part1].

A Vary header field-value of "*" always fails to match and subsequent requests on that resource can only be properly interpreted by the origin server. @@ -1099,7 +1098,7 @@ place certain constraints on the operation of shared caches in order to prevent loss of privacy or failure of access controls.

2.8 Errors or Incomplete Response Cache Behavior

A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) MAY store the response. However, the cache MUST treat this as a partial response. Partial responses MAY be combined as described in [Part 5]; the result might be a full response or might still be partial. A cache MUST NOT return a partial response to a client without explicitly marking it as such, using the 206 (Partial Content) status code. +

A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) MAY store the response. However, the cache MUST treat this as a partial response. Partial responses MAY be combined as described in Section 5 of [Part5]; the result might be a full response or might still be partial. A cache MUST NOT return a partial response to a client without explicitly marking it as such, using the 206 (Partial Content) status code. A cache MUST NOT return a partial response using a status code of 200 (OK).

If a cache receives a 5xx response while attempting to revalidate an entry, it MAY either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it MAY return a previously received response unless the cached entry includes the "must-revalidate" cache-control directive (see Section 3.2). @@ -1111,7 +1110,7 @@

We note one exception to this rule: since some applications have traditionally used GETs and HEADs with query URLs (those containing a "?" in the rel_path part) to perform operations with significant side effects, caches MUST NOT treat responses to such URIs as fresh unless the server provides an explicit expiration time. This specifically means that - responses from HTTP/1.0 servers for such URIs SHOULD NOT be taken from a cache. See [Part 2] for related information. + responses from HTTP/1.0 servers for such URIs SHOULD NOT be taken from a cache. See Section 8.1.1 of [Part2] for related information.

2.10 Invalidation After Updates or Deletions

The effect of certain methods performed on a resource at the origin server might cause one or more existing cache entries @@ -1259,7 +1258,7 @@

Indicates that the response MAY be cached by any cache, even if it would normally be non-cacheable or cacheable only within a non-shared cache. (See also - Authorization, [Part 7], for additional details.) + Authorization, Section 2.1 of [Part7], for additional details.)

private @@ -1510,7 +1509,7 @@

The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time.

The format is an absolute date and time as defined by HTTP-date in [Part 1]; it MUST be in RFC 1123 date format: +

The format is an absolute date and time as defined by HTTP-date in Section 3.3.1 of [Part1]; it MUST be in RFC 1123 date format:

   Expires = "Expires" ":" HTTP-date

An example of its use is

Based on an XML translation of RFC 2616 by Julian Reschke.

7. References

[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. +

[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. +

[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. +

[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, âHTTP/1.1, part 7: Authenticationâ, Internet-Draft draft-fielding-p7-auth-latest (work in progress), December 2007. +

[RFC1305]

Mills, D., âNetwork Time Protocol (Version 3) Specification, Implementationâ, RFC 1305, March 1992. @@ -1884,6 +1913,36 @@

Part1 2.2.3, 2.5.1, 2.5.2, 2.5.2, 2.6, 3.3, 7
- Section 3.3.1 3.3
- Section 4.2 2.6
- Section 4.4 2.5.2, 2.5.2
- Section 8.1 2.5.1
- Section 8.3 2.2.3
+
Part2 2.9, 7
- Section 8.1.1 2.9
+
Part3 2.5.2, 2.6, 7
- Section 3.2.2 2.5.2
- Section 4.1 2.6
+
Part4 2.3, 2.3.2, 7
- Section 2 2.3.2
- Section 3 2.3
+
Part5 2.5.3, 2.8, 7
- Section 5 2.5.3, 2.8
+
Part7 2.4, 3.2.1, 7
- Section 2.1 2.4, 3.2.1
+
Pragma header 3.2, 3.4

private

+ @@ -2385,6 +2387,697 @@ + + + + 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 2: Message Semantics + + + 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 4: Conditional Requests + + + 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 7: Authentication + + + 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 +

+ + + + + + + + MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text Modified: labs/webarch/trunk/http/draft-fielding-http/p7-auth.html URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p7-auth.html?rev=603063&r1=603062&r2=603063&view=diff ============================================================================== --- labs/webarch/trunk/http/draft-fielding-http/p7-auth.html (original) +++ labs/webarch/trunk/http/draft-fielding-http/p7-auth.html Mon Dec 10 13:51:25 2007 @@ -493,7 +493,7 @@

HTTP access authentication is described in "HTTP Authentication: Basic and Digest Access Authentication" [RFC2617]. If a request is authenticated and a realm specified, the same credentials SHOULD be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks).

When a shared cache (see [Part 6]) receives a request containing an Authorization field, it MUST NOT return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds: +

When a shared cache (see Section 2.7 of [Part6]) receives a request containing an Authorization field, it MUST NOT return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds:

Based on an XML translation of RFC 2616 by Julian Reschke.

6. References

[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. +

[RFC2616]

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, âHypertext Transfer Protocol -- HTTP/1.1â, RFC 2616, June 1999. @@ -652,6 +657,10 @@

Part6 2.1, 6
- Section 2.7 2.1
+
Proxy-Authenticate header 2.2
Proxy-Authorization header 2.3

Modified: labs/webarch/trunk/http/draft-fielding-http/p7-auth.xml URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p7-auth.xml?rev=603063&r1=603062&r2=603063&view=diff ============================================================================== --- labs/webarch/trunk/http/draft-fielding-http/p7-auth.xml (original) +++ labs/webarch/trunk/http/draft-fielding-http/p7-auth.xml Mon Dec 10 13:51:25 2007 @@ -11,7 +11,9 @@ SHOULD"> SHOULD NOT"> - + + + "> ]> @@ -134,7 +136,7 @@ - + @@ -357,6 +359,121 @@ + + + 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 +

+ + + + + + + + Hypertext Transfer Protocol -- HTTP/1.1 Modified: labs/webarch/trunk/http/draft-fielding-http/p8-cookies.html URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p8-cookies.html?rev=603063&r1=603062&r2=603063&view=diff ============================================================================== --- labs/webarch/trunk/http/draft-fielding-http/p8-cookies.html (original) +++ labs/webarch/trunk/http/draft-fielding-http/p8-cookies.html Mon Dec 10 13:51:25 2007 @@ -343,7 +343,7 @@ - + --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org For additional commands, e-mail: commits-help@labs.apache.org