Re: Inline content modification?

Robert Collins wrote:

> > 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?

The kind I was thinking about is where you slightly modify the URL to
get a modified content.

The problem with content modification combined with URL rewriting is to
make it consistent. What happens if the client sends a request for the
original URL? If modification is done on the server connection then the
client will get the modified content, which may not be what was
expected. This also affects peerings. Peerings will be done on the
"backend" URLs, where it might not be intended that the modifications
should be applied.

> 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.

HTTP allows for non-transparent proxies to do much whatever they like,
as long as some basic protocol parameters are fulfilled. Examples of
this are image recoding, automatic translation, and much whatever else
you can imagine.

A transparent (in HTTP terms) proxy however cannot do any such
modifications, not even on the URL.

/Henrik
Received on Wed Jan 17 2001 - 13:53:45 MST