in reply to Perl header to serve up a .HTML file from a CGI directory

Okay, Gramps, I know that you're really more clever than me on average, so I must be missing something... :)

Why would a web-data provider want to put html files in the cgi-bin directory? And/or why would a browser user find it more attractive to use a url like "www.hostname.xxx/cgi-bin/somepage.html", as opposed to something like "www.hostname.xxx/somepurpose/somepage.html" or just "www.hostname.xxx/sompage.html"?

On a unix-based web server, wouldn't a cgi-bin/foo.html file need to be flagged (chmod) executable? And/or would the web-server's config file need some tweak that enables *.html files to be treated as executable code? I don't doubt that the technique shown here is working for you, but I wonder if there might be some "issues" you haven't discussed that others might trip over.

  • Comment on Re: Perl header to serve up a .HTML file from a CGI directory

Replies are listed 'Best First'.
Re^2: Perl header to serve up a .HTML file from a CGI directory
by GrandFather (Saint) on Mar 14, 2007 at 04:02 UTC

    It was really just a quick way of dumping a mixture of "plain" html and HTML::Template fodder into the same place as the cgi scripts for testing. It's actually in a Windows Apache context so the executable flag's not an issue, but I wanted to keep the files together to make it a little easier to manage them with Subversion during the prototyping phase.

    I imagine these files are going to get a lot of hacking while I argue over site layout with the person who wants the work done.

    And of course you can factor almost complete ignorance of CGI, Apache and HTML/HTML::Template into all of that too - I've been writing CGI script and running an Apache server for testing for a few weeks.

    More clever at the XP game maybe - but I'm not sure that counts for a huge amount. Sure can't convert XP to cash. :-D


    DWIM is Perl's answer to Gödel