W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: draft-snell-http-prefer

From: James M Snell <jasnell@gmail.com>
Date: Fri, 12 Oct 2012 12:02:25 -0700
Message-ID: <CABP7RbdCzGRnAgA-HGODqEM6gLzZyzr4UOrNOVZU4hwGro6ecw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Ken Murchison <murch@andrew.cmu.edu>, ietf-http-wg@w3.org
Yes it would be useful, but unfortunately not possible given the way PUT is
currently defined. The only way it could work is if an intelligent
intermediary handled the return-representation on it's own, issuing a
subsequent GET to the origin server and sending it's own response back to
the client rather than relying on the server. Obviously, however, that's
not something we can rely on.

- James

On Fri, Oct 12, 2012 at 11:49 AM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> On 12 October 2012 10:11, Ken Murchison <murch@andrew.cmu.edu> wrote:
> > In other words, is there a way to make the response suitable for a cache
> to
> > use it to satisfy subsequent GET/HEAD requests, in the same way that POST
> > responses can be?
>
> p2 is quite clear on PUT and caches: PUT invalidates caches and nothing
> more.
>
> My hope was that the rules for indicating that a response is cacheable
> would be more generally applicable than for just POST.  I can see how
> "return-representation" on PUT would be a useful optimization for
> cache population.
>
>
Received on Friday, 12 October 2012 19:03:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 12 October 2012 19:03:14 GMT