Subject: Re: Known Problems - Transparent Proxies and new HTTP Methods

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

Note: This is more of an implementation issue than a protocol issue, and
in part applies to normal proxies as well.

HTTP/1.1 specification allows a proxy to switch over to tunnel mode when
it receives a request with a method or HTTP version it does not
understand how to handle.

--
Henrik Nordstrom

Patrick McManus wrote:
> 
> Name:
>     Network Transparent Proxies Prevent Introduction of New HTTP Methods

---

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

a network transparent proxy that does not tunnel has created a defacto
firewall.. whereas with a normal proxy that does not tunnel the client
may choose to re-issue the request bypassing the proxy. 

Tunnelling is certainly not required.. as such it's an architectural
issue.

but, tunneling should definitely be added to the workarounds.. that's
a big over-sight.. Though you've got to admit its farcical to be
'network transparently tunneling' traffic that was never addressed to
you in the first place.

-P

In a previous episode Henrik Nordstrom said...
:: 
:: Note: This is more of an implementation issue than a protocol issue, and
:: in part applies to normal proxies as well.
:: 
:: HTTP/1.1 specification allows a proxy to switch over to tunnel mode when
:: it receives a request with a method or HTTP version it does not
:: understand how to handle.
:: 
:: --
:: Henrik Nordstrom
:: 
:: 
:: Patrick McManus wrote:
:: > 
:: > Name:
:: >     Network Transparent Proxies Prevent Introduction of New HTTP Methods
::

---

From: John Dilley <[email-masked]>
Date: Tue, 03 Aug 1999 15:20:05 -0700

Thanks for the clarifications.  I have updated the KP draft.  I
will be posting a version shortly.  This has been a productive day for
KP comments!  Thank you to all who have participated.  Regards,

			     --       jad       --
			  John Dilley <[email-masked]>
		  http://www.hpl.hp.com/personal/John_Dilley/

---

From: Wojtek Sylwestrzak <[email-masked]>
Date: Sun, 15 Aug 1999 23:48:23 +0200

Sorry for being late, but only now I realized that somehow
the focus of the draft seems to be on caching only and not replication,
right ?

this seems a little strange for a document describing 'current
practice',
considering that replication (aka 'mirroring') has been around well
before
people started thinking of caches..

Anyway - I have some specific comments about the "Inter-Replica
Communication"
sections, but I'm not sure if this has not been discussed already ?
Couldn't find much about web replication neither in the meetings minutes
nor in the list archives. Has there been any discussion on this offine
perhaps ?
any pointers ?

thanks,

--w

---

From: Wojtek Sylwestrzak <[email-masked]>
Date: Mon, 16 Aug 1999 16:58:07 +0200

firstly,
after reading the draft, the difference between caching 
and replication is not clear to me. 
perhaps the Terminology section would be the right 
place to define these  ?

otherwise I'm not sure whether prefetching/preloading cache
is caching or replicating ?
and what about the "reverse proxies" ?

my definition is that while caching is one of the means
of replication, characterised by *on-demand* transfers.

second question is rather my uncertainity about the meaning
of the word "web" in WREC. Perhaps wrongly, I understand
thar *web* replication is about objects that are to be
accessed by clients using http ? (not ftp, nntp or such).
Or is it about replicating web severs ?

these questions might seem naive (and they are), but 
the answers are important for the internal consistency
of the document.

--w

---

From: Wojtek Sylwestrzak <[email-masked]>
Date: Mon, 16 Aug 1999 17:18:40 +0200

my comments to:

5. Inter-Replica Communication

are marked with #:

5.1 Batch Driven Mirror Replication

      Authoritative reference:
             This memo.

      Description:
             In this model, the replica web server to be updated
             initiates communication with a master origin web server.

# shouldn't it be: "replica origin server"
# and: "master origin server" to be consistent with
# the terminology introduced earlier

# also I know examples where the transfer
# is inititated by the master not the replica.

             The communication is established at intervals based upon
             queued transactions which are scheduled for deferred
             processing. The scheduling mechanism policies vary, but
             generally are reoccuring at a specified time.  Once
             communication is established, data sets are copied to the
             initiating replica web server.

      Security:
             Relies upon the protocol being used to transfer the data
             set. FTP and RDIST are the most common protocols observed.

# if this is about *web* replication practice
# than my experience is that most popular protocols
# in use would be FTP, rsync and HTTP.
# CVSUP and rdist are also used, but rather seldomly

      Deployment:
             Very common for mirror synchronization in the Internet.

      Submitter:
             Document editors.

 5.2 Demand Driven Mirror Replication

      Authoritative reference:
             This memo.

      Description:
             In this model, the replica web server acquires the content
             as needed due to demand.  This is generally done by web
             server accelerators (reverse proxy) operating as origin
             server replicas.  When a web client requests a URL that is
             not in the data set or the replica origin server, the
             replica server attempts to acquire it from a master origin
             server and forwarded on to the requesting web client.

# here I'm confused - this is specific to caching,
# not web replication in general. why is it in this section ?

      Security:
             Relies upon the protocol being used to transfer the URLs.
             FTP, Gopher, HTTP and ICP are the most common protocols
             observed.

# i doubt if gopher or ftp is used to transport www objects ?

      Deployment:
             Observed at several large web sites. Extent of usage in
             the Internet is unknown at this time.

      Submitter:
             Document editors.

 5.3 Synchronized Replication

      Authoritative reference:
             This memo. [Ed note; there is no IETF protocol specified at
                         this time.  The editors are aware of at least
                         two open source protocols, AFS and CODA, along
                         with one expired IETF draft
                         <draft-leach-cifs-v1-spec-01.txt> and one
                         proprietary protocol Novell NRS; none of which
                         can be considered an authoritative reference]

      Description:
              In this model, the replicated origin servers cooperate
              using synchronized strategies and specialized replica
              protocols to keep the replica data sets coherent.
              Synchronization strategies range from tightly coherent (a
              few minutes) to loosely coherent (a few or more hours).
              Updates occur between replicas based upon the
              synchronization time constraints of the coherency model
              employed and are generally in the form of deltas only.

# isn't it about distributed file systems like DFS, AFS etc ?
# i think it's beyond the scope of this document.
# otherwise we should consider network file system as well
# like cached NFS or WebNSF 

--w

---

From: Wojtek Sylwestrzak <[email-masked]>
Date: Thu, 19 Aug 1999 00:30:53 +0200

hm, hm, noone seems to be into replication here ?

perhaps the WREC group should be renamed WC then ...

--w