- From: Adam Wierzbicki <adamw@icm.edu.pl>
- Date: Wed, 2 Apr 1997 14:09:44 +0200 (MET DST)
- To: Josh <josh@netscape.com>
- Cc: adamw@icm.edu.pl, http-wg@cuckoo.hpl.hp.com, jwr@icm.edu.pl, wojsyl@icm.edu.pl
Thanks very much for your help. > For a busy server, it generally makes sense for it to cache if it > has to retreive it anyway. Of course, we're assuming the object > isnt already in the cache-- if it is, then the proxy can potentially > return it from the cache. > The biggest cost for a proxy is the origin retreive (contacting the > web server ), writing a cache file is much cheaper. In addition, by > caching it, if there is a request for the same object, the proxy can > then return it from the cache next time, which helps the proxy a > great deal. > I think in a worst case scenario, it would be O.K. for the proxy to > act such that: "I am too busy to go to the far away web server for > you, but Ill give you what I have in my cache, even though its out > of date". The client can accept that or attempt to go direct. A very busy proxy is in a state resembling deadlock. It should not accept any new TCP connections, because it will not be able to serve them anyway. It might want to remember the request and fetch it later from the origin server. It should be able to communicate to the client to leave it alone. The response "I will not cache this" might be useful if a user agent is trying to place some information in a cache. Also, if a user agent does not follow exclusion standards, the proxy will take the blame. It might be useful to answer "I will not fetch this for you" to bothersome user agents.
Received on Wednesday, 2 April 1997 04:12:13 UTC