W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2004

Re: PATCH vs PUT w/Content-Range

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>
Message-ID: <20040428221623.GB3889@mail.shareable.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:30 GMT