Subject: Re: transparent proxies - the hot topic

From: Chuck Neerdaels <[email-masked]>
Date: Tue, 03 Aug 1999 14:05:52 -0700

Maybe we should differentiate "transparent proxy" and "transparent
redirection to a proxy cache." Whether it's correct or not, when most people say
the first, they mean the latter. 

chuck

Bertold Kolics wrote:
> 
> Hi,
> 
> I took a closer look at RFC2616. There one can read the following:
> 
> 'A "transparent proxy" is a proxy that does not modify the request or
> response beyond what is required for proxy authentication and
> identification. [...] Except where either transparent or non-transparent
> behavior is explicitly stated, the HTTP proxy requirements apply to both
> types of proxies.'
> 
> My question is: can we call a proxy transparent if it is unable to handle
> a request because it does not implement a method present in the request
> header?
> 
> IMO, the transparent proxy has everything it has to know about a request:
> the port and IP address of the origin server. Nothing else is needed.
> 
> Bertold

---

From: Patrick McManus <[email-masked]>
Date: Tue, 3 Aug 1999 17:22:32 -0400 (EDT)

we've been through this ad nauseum and are pretty clear in the
taxonomy draft. If people are going to pursue the issue again, please
be certain you've read that.

Also, please note that my problem reports explicitly referred to
'network transparent proxies' not simply transparent proxies. This is
not a coincidence.

The whole value of that work is in building other things.. like the
known problems draft.

-P

In a previous episode Chuck Neerdaels said...
:: 
:: Maybe we should differentiate "transparent proxy" and "transparent
:: redirection to a proxy cache." Whether it's correct or not, when most people say
:: the first, they mean the latter. 
:: 
:: chuck
:: 
:: Bertold Kolics wrote:
:: > 
:: > Hi,
:: > 
:: > I took a closer look at RFC2616. There one can read the following:
:: > 
:: > 'A "transparent proxy" is a proxy that does not modify the request or
:: > response beyond what is required for proxy authentication and
:: > identification. [...] Except where either transparent or non-transparent
:: > behavior is explicitly stated, the HTTP proxy requirements apply to both
:: > types of proxies.'
:: > 
:: > My question is: can we call a proxy transparent if it is unable to handle
:: > a request because it does not implement a method present in the request
:: > header?
:: > 
:: > IMO, the transparent proxy has everything it has to know about a request:
:: > the port and IP address of the origin server. Nothing else is needed.
:: > 
:: > Bertold
::

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 03 Aug 1999 23:30:04 +0200

Please read the taxonomy draft. There are multiple meanings of the word
transparent. The "definition" used in RFC2616 matches what you could
call "semantically transparent", and has nothing to do with knowing the
IP or port of the origin server.

To anwer your question, no a semantically transparent proxy probably
must be capable to forward any kind of request of the major HTTP version
being supported by the proxy. It may do so using either proxying or
tunneling.

Fully semantically transparent proxies are most likely outside the
responsibility of WREC as caching probably is not possible in a fully
semantically transparent proxy. You can however see "semantically
transparent" as a scale of level of semantic transparency. A caching
proxy may be conditionally semantically transparent, and so may a proxy
not forwarding other than a known set of methods.

--
Henrik Nordstrom

---

From: Bertold Kolics <[email-masked]>
Date: Wed, 04 Aug 1999 09:23:27 +0200 (MET DST)

Hi,

On Tue, 3 Aug 1999, Henrik Nordstrom wrote:

> transparent.

Thanks. I have read it again. I think that rephrasing Patrick's suggestion
is needed, because it seems to be confusing to me (maybe to others as
well): there is *no definition* for "network transparent proxy" in the
taxonomy draft.

Furthermore - just as a side-note: I do not really like to have two 
definitions for transparency in RFC2616 and the taxonomy draft. I think -
however - that it would be possible to provide a definition in the
taxonomy draft that *IS* compliant with the definition found in RFC2616.
It would be wise to have the same definition for "transparency", but other
definiton for "out-of-path transparent caching proxy" could be added.

Bertold

---

From: [email-masked] (Ian Cooper)
Date: Wed, 04 Aug 1999 08:04:43 GMT

>well): there is *no definition* for "network transparent proxy" in the

The need for the additional clarification "*network* transparent
proxy" was discussed at IETF in Oslo.  The comments are currently
being edited into the current draft before we send it out to the list
and resubmit.

>definiton for "out-of-path transparent caching proxy" could be added.

From what I remember, the general consensus is that we can't resolve
the differences between RFC2626 "transparency" and what we, the
caching community, have come to call a transparent cache.

In terms of defining transparency, I think that we've tried (and
failed) to define that single word, and have instead decided to
qualify the type(s) of transparency that are being discussed.  

It would be nice (for closure) to be able to come up with a definition
of that single word "transparency", so if you've got any ideas, please
send them to the list and/or editors.  It would be wise to make
yourself aware of the existing comments first (if you've not already
done this).

An archive of the mailing list and a copy of the minutes from Oslo are
at <URL:http://www.wrec.org/>.

Ian