Alex Rousskov wrote:
> I think, ideally, digests should not have request method included in the
> key. We index entities, not requests. Currently we just recycle whatever
> key Squid has computed.
Agreed (that method should not be part of the key), but with some
reservations until I have fully understod what the HTTP specification
refers to when it talks about cachability of responses to methods
besides GET/HEAD. For example, what is a cachable reply to the POST
method? Is it an entity representing the Request-URI the POST method
tried to address, or something else?
GET and HEAD it is quite obvious with respect to caches, both methods
operates on the same entity. POST does not.
There are two kinds of cachable replies to POST representing the
Request-URI which makes sense to me:
a) If POST returns the updated entity, as would have been seen with a
GET requests after the completetion of the POST requests.
b) Errors which are the same whichever method are being used, for
example 404 not found.
It also makes limited sense to say that POST replies are cachable based
on the request-entity (the data passed to POST), but that requires
almost infinite cache keys not based on the URI alone but also any data
sent with the POST request. Somewhat related to the Vary issue.. The
Vary header defines that a single URI can have several entities based on
who or what made the requests. Is POST a extreme variation of this
(varies based on request entity)?
/Henrik
Received on Tue Jul 29 2003 - 13:15:58 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:07 MST