- From: Shel Kaphan <sjk@amazon.com>
- Date: Fri, 5 Jan 1996 14:47:31 -0800
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http-caching@pa.dec.com
Larry Masinter writes: > > FWIW, I am opposed to including an entity body in a 'GET' request, for Jeff's reasons of downward compatibility, I agree. and > think POST-W-N-S-E is nonsense. For reasons of downward compatibility, I agree it is apparently unusable. And, following your reasoning below, it is not as flexible as it should be anyway. Whether the results of a POST is > cachable might depend on the request! And so, the server can insert appropriate Expires headers to indicate just how cachable the response is. For example, you might POST > something which is syntactically invalid, and let the client cache the > error message telling you how it was wrong, but syntactically valid > POST requests would be sent along, have side effects, and thus not be > repeatable or cachable. The indication of the transaction status of a > request should be included in the response, not deduced from the > nature of the request, unless the response just doesn't say. > I agree, a response-based approach could certainly be more accurate and flexible. How exactly could we implement this? Suppose that instead of the HTML, browser, and request changes that I mentioned about 5 minutes ago, that servers inserted the Cache-control:no-side-effects header in appropriate *responses*. This then would be part of the cache's state for that particular request/response pair, and could control the cache's behavior for subsequent request of a similar nature. Yeah, I like it, and it requires less infrastructure change as well. Are we converging yet? --Shel
Received on Friday, 5 January 1996 23:08:43 UTC