- 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