Re: HTTP 'HASH' Method

Henrik Nordstrom wrote:
> [context: there == chunked encoding trailer]
> 
> Also doubt the server would be able to process conditionals based on
> ETag in such cases as you need to process the conditional before sending
> the response, and if the server is unable to build an ETag before it
> sends the response I don't see how it could implement the conditionals
> either..

Not quite the same, but related:

Some dynamic servers have server-side caches with complex
prerequisites.  For example, checking the timestamps of all files
(including code) and values of all database entries used to construct
the response - in more advanced schemes, with local invalidation
triggers so those checks are in O(1).

Those servers can efficiently validate an Etag corresponds to the
current version of a server-side cached response - without
regenerating the response.  So they can implement conditionals.

Conditionals even work _without_ a full server-side response cache -
only Etags and prerequisites need to be recorded, not the actual
content, which can be regenerated in the event of a cache miss.

However, those servers can easily generate an Etag in advance of any
calculations.  They just pick a random number for the Etag, and key
the real set of prerequisites against a local database mapping those
numbers to prerequisites.  (Much like is commonly done with opaque cookies).

Where the trailers would be useful is in specifying the Vary header.
Currently, if the server can determine which requests headers are
prerequisites for the page, before it sends anything, it can put those
in the Vary header.  If not, it has to send "Vary: *".  If it worked
to put Vary in a trailer instead, it could be more accurate in those
cases.

-- Jamie

Received on Sunday, 27 May 2007 22:40:38 UTC