Issue 39: proposed example for varying the etag based on conneg

Hi,

here's a proposal that would partly address 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/39>; after the 
introduction to entity tags, let's add an example that makes it crystal 
clear that entity tags may not be shared between responses negotiated on 
Accept-Encoding:

-- snip --
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 the transfer of the
       message, and thus do not require assigning distinct entity tags.

-- snip --

(<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/39/i39.diff>)

Feedback appreciated,

Julian

Received on Thursday, 25 March 2010 23:33:04 UTC