- From: Koen Holtman <koen@win.tue.nl>
- Date: Fri, 15 Dec 1995 11:13:49 +0100 (MET)
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Larry Masinter:
>
>When you do an HTTP method for a URL, the results may depend on things
>other than the method name and the path of the URL.
Larry, most of the problems you write about are addressed to some
extent by the 1.1 content negotiation mechanism, not the caching
mechanism. You may want to read my 'notes on content negotiation', I
believe they address some of your concerns about things currently
missing from 1.1. The notes are in
http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0289.html
and
http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0347.html .
[...]
>In those cases, the client/proxy needs to ask the server for the
>results of applying the method to the URL, but also indicate to the
>server which objects it DOES have cached for that URL.
In my notes on content negotiation, I proposed a new header
Send-no-body-for: <list of variant URIs>
for the purpose of indicating the variants the cache DOES have cached
for a negotiated URL (called a negotiation port in my notes).
It is interesting to note that the IF: (Unless) header allows one to
implement the functionality of my proposed Send-no-body-for
header. Roy's
If: {ne {Location "http://blah.com/doc.french.html"}}
would have about the same semantics as my
Send-no-body-for: http://blah.com/doc.french.html .
Reading your message, it seems to me that we have both independently
concluded that `Send-no-body-for' functionality is needed.
Koen.
Received on Friday, 15 December 1995 02:17:11 UTC