- From: Jamie Lokier <jamie@shareable.org>
- Date: Wed, 28 Apr 2004 23:16:23 +0100
- To: Alex Rousskov <rousskov@measurement-factory.com>
- Cc: Lisa Dusseault <lisa@osafoundation.org>, HTTP working group <ietf-http-wg@w3.org>
Alex Rousskov wrote:
> > I do mention one reason in the draft -- the problem of write-through
> > caches. The cache (if an intermediary) could see a PUT with a body and
> > save the body as the new body for the resource, even though the PUT
> > request body is only a diff or content range.
>
> Does anybody know of any implementation that caches PUT bodies?
I don't know.
It would be a violation of RFC 2616 (HTTP/1.1) section 13.10 though:
In this section, the phrase "invalidate an entity" means that the
cache will either remove all instances of that entity from its
storage, or will mark these as "invalid" and in need of a mandatory
revalidation before they can be returned in response to a subsequent
request.
Some HTTP methods MUST cause a cache to invalidate an entity. This is
either the entity referred to by the Request-URI, or by the Location
or Content-Location headers (if present). These methods are:
- PUT
- DELETE
- POST
RFC 1945 (HTTP/1.0) does not say anything like this. It does say that
GET and HEAD responses can be cached, and POST responses must not be,
neither must responses with Authorization. HTTP/1.0 doesn't have
anything explicit to say about the cacheability of PUT, so an
implementation might conceivably have done it.
-- Jamie
Received on Wednesday, 28 April 2004 18:16:40 UTC