Re: Inline content modification?

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Joe Cooper" <joe@swelltech.com>
Cc: "Squid Dev" <squid-dev@squid-cache.org>
Sent: Wednesday, January 17, 2001 7:29 PM
Subject: Re: Inline content modification?

> Robert Collins wrote:
>
> > BTW: client_side is good for filtering too - I was pointing out that for a accelerator that alters every request with those
URL's,
> > server sided is more efficient. For altering based on username/client-agent or a number of other things, client_side is more
> > efficient. What I'm building hooks filters in at four different locations: incoming data request & response, outgoing data
request
> > & response.
>
> A small warning about server-side content modifications: If you intend
> to peer with others, then server-side content modifications is generally
> a bad idea. This because the cached modifications are on the real URL,
> and your peers won't be able to distinguish between rewritten and
> original content for those URIs.

Yes. Agreed. For backbone caches, or caches that server other administrative domains this is a bad idea (except perhaps virus
scanning? )

> For an accelerator it makes sense to do it on the server connection.
> Especially so if the accelerator is set up without URL rewriting (see my
> recommendations on accelerator setups)

Yup.

> For a transforming proxy without URL rewriting it makes sense.
>
> For a transforming proxy with URL rewriting it is a bad idea, and is
> better done in the client side.

I'm not 100% clear on what a transforming proxy with url rewriting is - a combination of squirm and language translation say?

> For an accelerator farm where the farm members peers with each other
> care needs to be taken so the content isn't modified multiple times by
> each accelerator in the object path.

For sure.

Filters are data filters, not HTTP protocol violators per se - they can be used for that, but also to easily implement parts of the
spec : IMO some parts of the HTTP spec are best implemented as filters - I.E. the TE code is about to become a filter.

Rob
Received on Wed Jan 17 2001 - 02:53:32 MST