> You avoid the buffering problems because you dont buffer at all. You just > examine the words as they are downloaded. and as long as they dont violate > your filtering rules, you allow the datastream to continue to the user's > browser. When the filter rules are triggered, you just send a string like > "

This page has triggered the filter

The Connection has been > terminated". Ah, I see what you mean. Any thoughts on how one would code something like that? I'm thinking along the lines of STDIN/STDOUT through a perl script or sed or something. For example, I regularly pipe tcpdump output through sed to make the output more readable on a character terminal attached to my firewall. However, I'm really at a loss on how I could situate my script between the requesting client and the responding webserver. Check this out. I tried a little experiment with netcat: # echo -e Success'\n'Cool > ./wordlist # cat ./wordlist Success Cool # echo -e GET / HTTP/1.1 '\n' | nc google.com 80 | grep -f ./wordlist

Survey Says: Google Success Continues


Cool Jobs - Try o ur Web Directory - Advertise with Us
As you can see, I grabbed the default webpage from google and filtered it through my wordlist without buffering anything (at least I don't think it's buffering). Seems like I could instead pipe to a script that uses sed and/or awk to search for keywords and replace all text if a hit occurs. However, I still don't know how to position it between server and client. > If it were me doing such a filter, I would have all filters triggered in > that manner put into a check list. Then someone could look over the list > once a week or so and then apply the list to a list based part of the > filter. Yes, that is an add-on I had in the back of my mind. I haven't given it much thought yet, but it sounds resonable on the surface, right? ...Kevin