On Thu, 24 Jun 1999 13:08:55 -0400 (EDT), Patrick McManus wrote:
>
>some suggestions..
>
>In a previous episode Ian Cooper said...
>::
>:: proxy
>since this is the introduction of [non-]transparent perhaps a line
>like: "HTTP defines [non-]transparent as above, but industry usage
>typically carries different semantics as described below. Further
>unspecified references to transparency in this document fit with
>{HTTP|industry} usage."
Agreed.
>:: cache
>:: A program's local store of response messages and the
>:: subsystem that controls its message storage, retrieval, and
>:: deletion. A cache stores cacheable responses in order to
>:: reduce the response time and network bandwidth consumption
>:: on future, equivalent requests. Any client or server may
>
>'equivalent requests' is a problem.. consider Accept headers and q
>values and their interactions with proxies.. a proxy may very well
>choose to give the same response back to two subsequent requests that
>would have generated different variants if presented directly to the
>origin server.
Doesn't RFC2616 say something about that somewhere? I don't have the
time to look it up right now, so if anyone know...?
>:: transparent proxy (additional definition)
>:: the term "transparent proxy" is defined in [6] (and quoted
>:: above). However, in the realm of Web caching, this has
>:: come to define a proxy which receives traffic as a result
>:: of network traffic interception. The term typically
>:: describes the use of a proxy and the additional systems
>:: which performing network traffic interception. The use of
>:: the proxy is transparent to the client.
>
>if we're going to describe the motivations of including cache (reduce
>latency, save badwidth, increase availability..) we should probably
>include the motivation for transparent proxies too: no need for client
>configuration (auto or otherwise).
Agreed.
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:26 MST