>> If you need to, either change the extension for CGI or change the >> extension for the scripts themselves. > > What a novel idea :-) I'll just change the extensions of the scripts > (currently removing them entirely) rather than walking through the > landmined path of screwing with the CGI's. You could also have a cgi that acts as a catalogue program, serving up cgi's by request using "Content-type: text/plain\n\n" to deliver the scripts. That would be my preferred method, as it keeps the naming conventions intact and in the long run makes serving them much easier and automated. >> But won't WebTen key off type/creator instead of extension, or is it >> so much just Apache that they haven't given it that capability? > > I don't know the answer to that. I'm using the WebTen 3.0 beta, which > is awaiting only the documentation to become a released version. I'll > look in the 2.1 documentation for my own curiosity. WebTen does, under certain circumstances, look at creator/type of a file. Even if its system is rather "smart" and can map c/t to a mime type, file name extensions take precedence. Otherwise it couldn't determine between an html file and a cgi script written in BBEdit (same c/t). The only time c/t matters more is when a file is recognized as a WebTen native file vs a regular mac file. -K # ===== Want to unsubscribe from this list? # ===== Send mail with body "unsubscribe" to macperl-request@macperl.org