On tis, 2008-11-18 at 10:40 -0800, Mark Nottingham wrote:
> 1) Major shared cache implementers interpret it this way (see Henrik's
> mail, for example).
>
> 2) Allowing non-GET methods to be cacheable will IMO encourage the
> development of GET-like extension methods. This will result in a lot
> of data and metadata that isn't "on the Web" (i.e., you can't just
> dereference a link to obtain it; now you need to know the correct
> method as well).
>
>
> #1 may be a stronger reason to go this way as per our charter, but I
> think in the long run #2 is a stronger motivation.
Yes. #2 is the important one imho.
In our implementation we actually do keep the method as an internal part
of the cache key, but that's for other reasons, and if I were to
reimplement the cache today the method would not be part of the key
getting rid of a lot of special cases..
Regards
Henrik