As far as Apache is concerned, the script shown in Example 12.1 has nothing to do with any of the authentication and authorization schemes that Apache may be using. The script itself, in other words, is unprotected. There’s no directive in httpd.conf that names /cgi-bin as a protected directory, so there’s no trigger that causes Apache to issue an authentication challenge. When a user tries to run the script, it acts autonomously to provide its own authentication and authorization.

If you try the same thing with IIS, though, you’ll find that the script behaves differently. The browser can’t log in with any random credentials, as in the Apache case. It can only authenticate with the credentials of a real user listed in the server’s local domain or in the domain to which the server belongs.

This behavior is arguably a bug. Even though the script isn’t declared to IIS as a protected resource, IIS—seeing the incoming Authorization: header—steps in and decides to authenticate the credentials against the NT domain. Only a valid domain user—albeit any user!—can pass. It’s not clear what resource IIS thinks it is protecting when it does this. The behavior might be OK if you want to write a script that uses generic domain authentication but then provides its own custom authorization—such as the documents-by-subscribed-company rule that we want to enforce. But it’s not OK if you need to support subscribers who aren’t domain users. Are you out of luck in this case? No, but you can’t solve this problem in Perl (at least not yet). You’ll have to fire up a compiler and build a simple ISAPI filter.