- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Mon, 08 Jan 96 17:14:08 PST
- To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
- Cc: http-caching@pa.dec.com
One more comment on Roy's analysis:
2) By default, no other response code or request method is cachable.
Rationale: Almost all other request methods and error or
special-purpose responses are not cachable by their very nature --
either they represent once-only responses or they are not worth the
risk and/or storage requirements to justify caching.
I'm not sure what you meant here by "by default"; did you mean that
a server could explicitly make other methods cachable but by
default they are not? Or did you mean "By design"?
Anyway, I would certainly not argue in favor of standardizing
on something that we don't understand well, nor would I argue
in favor of any mandatory protocol features designed to make
rare optimizations work better.
At the same time, if we can come up with reasonably simple
and definitely safe protocol features that would make caching
of other kinds of responses possible, and if these do not
make other parts of the protocol worse or more complex, why
not do it? We could have endless arguments about the likelihood
of scenarios that have been suggested for cachable results
from POSTs and PUTs, and we will never resolve them soon enough.
If someone makes a plausible case for a few of these scenarios,
we should take it seriously.
-Jeff
Received on Tuesday, 9 January 1996 01:18:21 UTC