Application-Specific Proxy Servers as HTTP Stream Transducers

One-line summary: Use HTTP proxies, possibly arranged in a hierarchy, to do other tasks like measuring the network, transforming content, filtering content or requests, enforcing security, etc. A uniform architecture & toolkit for doing this is offered.

Overview/Main Points

• Allow proxies to do content transformation, filtering of requests, filtering of content, group annotation, etc.
• Proxies can be arranged in a hierarchy to exploit group locality for caching, filtering, collecting statistics, etc.
• Standard "wafer" (processing layer, =1 proxy) is called an OreO.
• Delay induced by pass-thru Perl "shell" is 3-6%; various simple tests done to judge whether users could perceive additional delay. Conclusion: like the DEC WRL cache, users are accustomed to network variability, and so do not notice proxy delays.
• Interesting idea: their customized browser sends an "X-Backchannel" header, denoting a TCP port on which browser is willing to accept connections for command directives.

Relevance

Obvious. We should cite this in all proxy papers -- it's the first I've seen that advocates transcoding as an explicit proxy property, even if not for the same reasons we advocate it.

The idea of "stackable proxies" is nice, and is something I am working into Pythia; as is the backchannel idea (similar to the net monitor in our world). This is from WWW4, but it has a lot of ideas in common with us.

Flaws

• The "toolkit" is really just a "shell wafer" that execut es a pipeline to do the transducing. Pythia is more flexible since it also specifies how transcoders can be parameterized by content-type and specifies an interface to the function that makes the distillation decision; they mention some similar behaviors as being on their "wish list".
• Lots of good ideas about other stuff proxy could be used for (controlling browser via backchannel, e.g.) We should follow up on what they are doing.