- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 23 Jul 2010 16:26:31 +0200
- To: Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
On 22.07.2010 14:56, Mark Nottingham wrote: > The editors believe that the following issues have been addressed by the -10 round of drafts. See<http://trac.tools.ietf.org/wg/httpbis/trac/report/15> for details; barring objections, they'll be closed soon. > ... Hi, we just figured out that an addition to P4 in -10 may allow us to close issue 39 as well: 2.1. Example: Entity Tags varying on Content-Negotiated Resources Consider a resource that is subject to content negotiation (Section 4 of [Part3]), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (Section 5.3 of [Part3]): >> Request: GET /index HTTP/1.1 Host: www.example.com Accept-Encoding: gzip In this case, the response may use the gzip Content Coding or not. If it does, it might look like that: >> Response: HTTP/1.1 200 OK Date: Thu, 26 Mar 2010 00:05:00 GMT ETag: "123-a" Content-Length: 70 Vary: Accept-Encoding Content-Type: text/plain Hello World! Hello World! Hello World! Hello World! Hello World! A variant that does use gzip Content Coding would be: >> Response: HTTP/1.1 200 OK Date: Thu, 26 Mar 2010 00:05:00 GMT ETag: "123-b" Content-Length: 43 Vary: Accept-Encoding Content-Type: text/plain Content-Encoding: gzip ...binary data... Note: Content Codings are a property of the response entity, thus affect the Entity Tag. An alternative are Transfer Codings (Section 6.2 of [Part1]) which apply only to the transfer of the message, and thus do not require assigning distinct entity tags. (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p4-conditional-10.html#rfc.section.2.1>) ...this essentially adds the case people were confused about as an example. Best regards, Julian
Received on Friday, 23 July 2010 14:27:21 UTC