Random notes

Random notes

General notes on Apache
A mod_perl script for sending mail
A mod_perl filter for email address obfuscation

General notes on Apache

Apache sucks. That's my bottom-line observation after having used Apache for two years, then AOLserver for four years, and now coming back to Apache.

AOLserver has a much more intuitive API and much better documentation. The user community is much smaller, but ther people involved are active and it doesn't take too long to get questions answered. The only reason I'm not using AOLserver right now is because it doesn't run on my machine, which runs debian on a HPPA processor.

When I started using Apache, I was impressed with how comprehensive the documentation looked, until I tried to do something that wasn't in one of the examples. Here's how it went:

Install Apache (2.0.47) along with the modules mod_access and mod_alias. Took a while to configure and compile, but went successfully without a hitch.
Install mod_perl (1.99_09). This needed several other packages to be installed, and still more to be able to run the make test properly. Took about three hours before I had everything working. mod_perl is invoked from my httpd.conf file thus:
```
LoadModule perl_module modules/mod_perl.so
PerlRequire "/usr/local/apache2/perl/startup.pl"
```
I wanted to redirect all incoming requests to http://www.mydomain.com/ to http://www.mydomain.com/naveen/. The documentation for mod_alias made it seem like this was a cinch. Unfortunately after fighting with it for two hours I couldn't make it work. It would either not work at all, or produce an infinite loop of redirections.
A web search revealed that some people were using mod_rewrite to do this. I tried to use it, but it turned out that I didn't have the module installed. And the Apache documentation doesn't mention anywhere how to add a module post-hoc, once the compilation has been done. I bit the bullet and compiled Apache again, this time also enabling mod_rewrite and mod_cgi. Took another hour or so.
Now I was able to get the redirection to work. In AOLserver, when I'd tried to do this four years ago, it took about 3 minutes to get it to work, and it worked right out of the box.

Apache is made up of a bunch of different modules, which are all documented separately, and if you're trying to make them do something together, then it may or may not work right out of the box. Especially if you're trying to do something that's not directly in the examples. For example, see my experience with the mod_perl script for sending mail below.

A mod_perl script for sending mail

I wanted to write a simple script to send me mail. It turned out to be a lot harder than I expected:

I made a simple HTML file that created the form, and made the submit button of the form go to the mod_perl handler. But then nowhere in the mod_perl documentation is it mentioned how one retrieves the form variables. I couldn't believe it. I looked and looked and looked. Tried all kinds of things, but nothing would work. Tried to use CGI.pm from inside of the mod_perl handler, but that kept throwing wierd errors like it needed "Apache::RequestRec" (which I was already loading).
Part of the reason I was suffering was because the bulk of the documentation and tips out there are for mod_perl 1.2 (which is intended to be used with Apache 1.3), and I'm using mod_perl 1.99_09 (and Apache 2.0.47). Neither mod_perl nor Apache are fully backwards compatible.
Here is an example: Chapter 6 of the O'Reilly Practical mod_perl book says that the mod_perl equivalent of the CGI API is the Apache::Request API. This is part of package called libapreq. But when I downloaded the package and tried to install it, it turned out that it would only work with mod_perl 1.28 through 1.98. Not with 1.99 and beyond. So I was screwed. I was pulling my hair out in exasperation. It was such a simple problem, and Apache and mod_perl were making it so hard.
After struggling for about four hours, I gave up on making a mod_perl handler, and just went with a simple script. Now I could use CGI.pm like expected and it worked fine.
To set up perl scripting with mod_perl (as opposed to a mod_perl handler), you need to setup a directory in your httpd.conf file:
```
Alias /cgi-bin /web/cgi-bin

<Location /cgi-bin>
    SetHandler perl-script
    PerlResponseHandler ModPerl::Registry
    Options +ExecCGI
</Location>
```
Now all files in the /web/cgi-bin directory will be treated as mod_perl perl scripts. Or so I think.
Then, you need two files: one that sets up the form and a second that sends the email. The first one doesn't need to be a perl script, but I made one anyways because I also wanted to embed the referring page into the form (as a hidden element) so that it can be offered to the user after the mail has been sent.
The two perl scripts I use to accomplish these are called send-mail.pl and mailform.pl. (Yes, I realize that these names are backwards.) They are both in the directory mapped to /cgi-bin in httpd.conf file, so that they can be accessed like /cgi-bin/send-mail.pl. The second script uses MIME::Lite to send the mail. It is a simple text mail, so you don't really need a fancy program to send it, but I used one anyways.

Hiding my email address from web crawlers

My email address has been on the web since 1994. I receive between 30 and 80 junk emails every day. In August 2003, I finally decided to hide my email address from web crawlers, which is how junk mailers get the addresses on their lists. Here is my strategy: the HTML for the email address has mixed-in ISO characters, so that it looks the same to a human being looking at the page in a browser, but a web crawler (or a human being looking at the source of the web page) cannot parse it. And the email address, instead of being a usual mailto: link, is a link to a web form where you can send me email (see above).

For example, instead of the usual HTML that would read:
<a href="mailto:me@here.com"><em>me@here.com</em></a>
I would like to generate HTML that reads:
<a href="/cgi-bin/send-mail.pl"><em>me@here.com</em></a>
The HTML of the email address in the second line reads the same in a web browser as the first line, but cannot be parsed by a web crawler (unless it is enormously sophisticated, and in which case we'll have to think of something else).

Here's how I've implemented this scheme:

All of my html pages are unchanged (they still have my email address and the mailto: links).
There is a perl filter for all files of type *.html, to replace all instances of my email address with an ISO-obfuscated email address, and the mailto: link with a link to a form that sends me mail.
The starting point for this filter was the mod_perl filters documentation.
The script I use would be just like the example script right at the top of that page, only (as that page mentions) that script scans the page in 1024 byte chunks, and if the pattern that you're trying to replace is spread across two chunks, then it will fail to replace it.
Much further below on that page is the script that overcomes this limitation with some classic perl-style obfuscated logic. That is what I based my script on. You can see my filter script here. It is setup in httpd.conf like so:
```
<Files ~ "\.html">
    PerlOutputFilterHandler MyApache::EmailObfuscate
</Files>
```

agni@mit.edu