Re: cache validators

Roy T. Fielding:
>[Jeffrey Mogul:]
>>       If-Match:
>>       If-NoMatch:
>> 
>> so that neither the word "validator" nor the word "identifier"
>> nor the word "Token" appears in a request header.  It also
>> makes it easier to remember what these mean, I think.
>
>No.  It is an entity identifier -- a strong EID identifies a single
>entity of a Request-URI, and a weak EID identifies a set of equivalent
>entities of a Request-URI.  That is exactly how we want the implementor
>to think about it and its purpose.

I agree with you: this is the image we want in the mind of the implementer.
However, to make this come true, we will have to rewrite some parts of the
spec.

The spec now defines entities as things that travel over the wire, not as
things `of a Request-URI'.  The distinction becomes important when you
start talking about ranges. See for example this text from the draft:

  206 Partial Content

   The server has fulfilled the partial GET request for the resource. The
   request MUST have included a Range header field (Section 10.33)
   indicating the desired range. The response MUST include a
   Content-Range header field (Section 10.14) indicating the range
   included with this response. All entity header fields in the response
   MUST describe the actual entity transmitted rather than what would
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   have been transmitted in a full response. In particular, the
   Content-Length header field in the response MUST match the actual
   number of OCTETs transmitted in the entity body. It is assumed that
                                ^^^^^^^^^^^^^^^^^^
   the client already has the complete entity's header field data.

I have been worrying about the above text some time: it breaks the mental
link between resources and entities we want to make.  It had lots of
trouble staying `compatible' with the above text when writing the text for
the Vary header.

If the 206 text above were adjusted to talk about `range entities'
traveling over the wire, and if a terminology description were added like
this:

  range entity

     An entity containing a subrange of the data in a particular full
     entity associated with a particular resource.  Range entities can be
     sent by servers in responses to partial GET requests.

_then_ we could start talking about `entities of a resource'.  I don't know
though if we'll have the time left to make edits to the draft in this area:
maybe talk about `entities of a resource' will have to wait for a separate
explanatory document.  If it does have to wait, I'd rather call the header
something neutral, like If-Match, as per Jeff's suggestion.  If we can
indeed fix range terminology in the 1.1 draft, I would have no problem with
If-EID.

>.....Roy

Koen.

Received on Sunday, 14 April 1996 17:23:37 UTC