cLive ;-) has asked for the wisdom of the Perl Monks concerning the following question:

Scratching my brain for a while over this one...

I have a form on one domain that posts to a script on another. I have configured apache to default to index.cgi. If I start the form up like this:

<FORM ACTION="http://script-domain.com/script_dir">
the script runs, but no form vars are available through param().

But if I do this:

<FORM ACTION="http://script-domain.com/script_dir/">

or this:

<FORM ACTION="http://script-domain.com/script_dir/index.cgi">
the vars are available to param().

Any ideas why the script runs in the first case, but without any of the vars sent?

very perplexed...

cLive ;-)

Replies are listed 'Best First'.
Re: CGI.pm bug? Or Apache issue?
by Teenage Mutant Ninja Camel (Initiate) on Aug 30, 2001 at 00:20 UTC

    Well, by requesting without the trailing "/" you're asking for a file named "script_dir", which apache is then doing an internal redirect to the directory "/script_dir/." Apache is then picking up your rule that sets the default to index.cgi after the internal redirect.

    It isn't that suprising, at least to me, that you'd lose the environment variables, including the posted data because of the redirect.

    When you request "script_dir/" with the trailing slash, you're avoiding the needed internal apache redirect, and keeping the environment variables.

    That's a long way to say "always end requests for directories with a trailing slash for performance's sake, and CGI.pm is still the bomb."

      Apache actually issues an external redirect in the 'dir lacking backslash' instance. This helps keep relative links from breaking. (i.e. where is ./me.jpg relative to http://whatever.com/onedir/anotherdir? Could be at onedir/me.jpg, or anotherdir/me.jpg.) Issuing the external redirect helps clear this up.

      -Blake

        Oops. My bad on the "internal vs. external" thing.

Re: CGI.pm bug? Or Apache issue?
by blakem (Monsignor) on Aug 30, 2001 at 00:22 UTC
    This looks like an apache thing.... requests to directories that lack trailing slashes are typically '302 redirected' to a page with a trailing slash. i.e.
    http://whatever.com/abc => 302 => http://whatever.com/abc/
    In this case if it is a POST, you'll lose your params (see POST redirect), but depending on your setup a METHOD=GET might be able to keep them.

    -Blake

Re: CGI.pm bug? Or Apache issue?
by dga (Hermit) on Aug 30, 2001 at 00:22 UTC

    That is interesting that it runs on the first URI. If a browser sends that your server probably sends a redirect message with the second URI. If you asked which would actually run the script I would have said 2 and 3 but not 1 so that in itself is interesting.

    I wonder if your client program is taking the redirect and reposting without the relevant form input data?

    Update: Look in your logs and see if there is a 304 near your other requests (The redirect) This would tell you the URL was hit twice but the script ran once once the redirect was followed.

    Update2: Oops as pointed out 304 is not right, It's 302 or 301 depending.

      If /foo is a directory, and DirectoryIndex is set to index.cgi, then a request for /foo yields an external redirect to /foo/, and a request to /foo/ yields an internal redirect to /foo/index.cgi.

      BTW 304 is "not modified", a response to an If-Modified-Since or similar conditional request. Redirects are 301 and 302.

Re: CGI.pm bug? Or Apache issue?
by echo (Pilgrim) on Aug 30, 2001 at 00:28 UTC
    you're right, except for one thing, the POSTed params aren't environment variables, they are sent in the body of the request, the CGI process picks them up from its STDIN. I'm just nitpicking really.

    IMHO the poster shouldn't rely on a DirectoryIndex config setting but rather identify the resource (the cgi) explicitely anyway.

Re: CGI.pm bug? Or Apache issue?
by cLive ;-) (Prior) on Aug 30, 2001 at 01:39 UTC
    Thanks all.

    I get it...

    cLive ;-)