In a previous episode Joe Touch said...
:: >
:: > [..]
:: >
:: > (network) transparent proxy
:: > [..]
:: > The use of this type of proxy
:: > is transparent to both user and client.
:: >
:: > >>> Using 'transparent' in the definition of 'transparent proxy' seems
:: > to be asking for trouble.. even I am not sure if this statement is
:: > meant to mean
:: > a] not detectable
:: > b] not relevant/not a factor operationally
:: > c] transparent in the non-transforming HTTP sense
:: > or d] does not require cooperation from client
::
:: Transparent means "not detectable at some layer" - in this case,
:: it is the application that cannot detect it.
Finding their presence really is not particularly hard [*].. but
that's a rathole that I think will just distract the group into a
debate we've already had and prevent us from creating some solutions
to existing issues.
we don't need to have this fight again though.. I'm in no way trying
to get the taxonomy to rag on ntp's more.. I just want this definition
to match the one for traffic redirection which says that it is "used
to deploy (caching) proxies without the need to manually reconfigure
individual user agents, or to force the use of a proxy where such use
would not otherwise occur." the document already says that.
I was pretty sure that the definition included in this paragraph was
meant to mean (casually) "they give you a semantically similar
response as the one a client would have received to the exact same
request made not in their presence".. which is to say that to use
them, the client need not take specific action... which is fine by
me. Giving me an old coke when I ask for a soda from a store that used
to serve coke but now serves pepsi is close.. it's probably even
acceptable for a short period of time; but it's not "not detectable"
at the application layer.
::
:: > A and B are clearly not true.. C is probably true, but I don't
:: > think it's the motivation for the statement.. so I think it must
:: > mean D.. so how about: "The use of this type of proxy requires no
:: > configuration either by the user or the client."
::
:: "No configuration", "user", and "client" do not necessarily apply.
I think you're just being contrary, but I'll bite. Why not?
(understanding that user means 'operator of the user agent' not
'operator of the proxy')
::
:: No _application_ configuration might. But that's not the only intent
:: of transparent. Not only is it not configurable, it isn't even detectable
:: at the layers above it.
::
again: very detectable.. and problematic. also, application isn't
a useful word without a definition in the taxonomy.. client is already
there; we know exactly what it means (a client initiates a request and
recevies a response, a server receives a request and sends a
response)..
network transparent proxies provide a means by which the client need
not be configured either on the client level (via something like wpad,
dhcp, etc..) or explicitly by the user and the client still gets some
benefit from the proxy. That's all that they do that we can agree on
100% so we should say that.
-P
---[*] the application certainly can detect it.. at least after getting back a response! These things cause real operational problems. I hope we all know that. But ignore the problems for a minute: anything remotely bordering on 2616 compliant has to add a Via header (a MUST).. this is doubly impt for something intercepting traffic as the Via header is for tracking paths and sorting out interoperability bugs. and then there is the squid setup I keep around for diagnosing these things.. it adds a X-Cache and Age headers to it's 'transparent' responses! They're not the same as direct responses.. that's how a client can tell the difference.
plus the operability problems: we all know the interaction problems in between requests directed to origin servers that are handled by 'network transparent proxies' and the problems with the absence of associated proxy directives that otherwise would have been there.. not to mention the problems with IP restrictions.. and migrations of new HTTP methods, etc..
ISPs will tell you that users do notice when you put in 'transparent proxies'.. and they call the help desk. It's not like replacing token ring with 802.3 (a lower level change that would be transparent to the application layer) exactly because the scheme 'level surfs' into the application domain. (rewriting requests and so on..)
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST