I chose to use HTML::Filter in the way that I did for a few reasons:
- The biggest reason was, it was very easy. The patch was 25 very fluffy lines of code and configuration. If you don't want to use HTML::Filter, it doesn't require you to have the module installed.
- It made it trivial to allow customization of the filters: you can easily configure the list of tags you want removed.
There's a much easier, faster way than either of our methods to disable anything dangerous whether we have or haven't thought of it. Not installing the proxy in the first place is the easiest solution, and requires the least amount of code and work to implement. But that doesn't make it a good solution, because you lose functionality you would otherwise have if you were willing to put in a bit more effort, and/or accept a certain level of risk.
The same principle applies here: HTML::Filter isn't as efficient in processing time or code size as something akin to s/</>/g; s/>/</g;. But it provides functionality that a few simple escaping regexes do not. If you don't need that functionality, then by all means make your design decisions differently. I chose an easily configurable solution partially because it allowed us to do what we needed to do, but also because the code allows other people to do what they need to do as well, even if they have different requirements than I do.
By way of an update:
I was able to contact the script's author, and I submitted my patch. The script is currently going through a rewrite, but he expects to release a patched version of the old code before the new version is available. The most important outcome is the fact that the author now knows of a problem in the script that he didn't know about before. If he decides to solve it some way other than the way I used, that's up to him. In the mean time, I'll use the solution I have.
Update: Sorry to sound defensive; I guess I misinterpreted the tone of your question :)