Back to index
Application-Specific Proxy Servers as HTTP Stream Transducers
Charles Brooks, Murray S. Mazer, Scott Meeks, and Jim Miller, WWW 4,
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.
- 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
- 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.
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.
- 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.
Back to index