Ingrid Melve wrote:
> How about using your comment as definition of transparent proxying,
> then remove transparent proxy and define either transparent redirection or
> traffic interception ?
Yes please. HTTP 1.1 already defines the term "transparent proxy", and
it is confusing to have more than one definition for the same term (even
thought, when most people speak about transparent proxying/caching they
are talking about transparent traffic redirection to a proxy/cache, not
a transparent proxy).
RFC 2616 (HTTP/1.1 draft standard), 1.3 Terminology
proxy
[...]
"transparent proxy" is a proxy that does not modify the request or
response beyond what is required for proxy authentication and
identification. A "non-transparent proxy" is a proxy that modifies
the request or response in order to provide some added service to
the user agent, such as group annotation services, media type
transformation, protocol reduction, or anonymity filtering. Except
where either transparent or non-transparent behavior is explicitly
stated, the HTTP proxy requirements apply to both types of
proxies.
And related to this it also defines transparency for a cache
semantically transparent
A cache behaves in a "semantically transparent" manner, with
respect to a particular response, when its use affects neither the
requesting client nor the origin server, except to improve
performance. When a cache is semantically transparent, the client
receives exactly the same response (except for hop-by-hop headers)
that it would have received had its request been handled directly
by the origin server.
Neither of these "transparent" definitions has anything to do with
traffic interception/redirection.
-- Henrik Nordstrom Spare time Squid hacker
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:26 MST