Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Re: HTTP Headers returned from CGI...

by andreychek (Parson)
on Jun 29, 2001 at 19:49 UTC ( #92692=note: print w/replies, xml ) Need Help??

in reply to HTTP Headers returned from CGI...

Well, are you certain that you actually have rights to run CGI scripts in the directory they are being run in? I'm not sure how that is all set up in Netscape-Enterprise, but with Apache -- one can't run CGI programs unless they are explicitely "turned on" in the Apache configuration file. Also, sometimes a web server can be set up to run CGI scripts from a particular directory, but not others. When this is the case, the dir is often called /webroot/cgi-bin.

I suppose the thing to do is to find out if other scripts in the same directory work. If so, do they have the same extension? Perhaps one file extension was allowed CGI access, but not another. Just a few things to look into... Since you don't have access to much of this, you may simply have to contact the servers administrator if you are unable to determine it remotely. HTH,

Update: I hate to assume anything, so I'll bring this up just in case. Since you have Perl code there, do make sure that you have the proper "shebang" line at the top of your script (something like #!/usr/bin/perl -w).

Replies are listed 'Best First'.
Re: Re: HTTP Headers returned from CGI...
by agent00013 (Pilgrim) on Jun 29, 2001 at 21:22 UTC
    for clarification: This CGI is on a different server. I can access it through Internet Explorer or Netscape and load it up fine. So I'm pretty sure it's "turned on." This is also why I don't understand being "Forbidden." If I'm not forbidden from my web browser, why would I be trying to access the script through PERL? Or is the problem that PERL is trying to access the CGI script itself and not the output it's creating?

    Yes, I have the right shebang. The program wouldn't give me any output if it wasn't in there. =)

    10.4.4 403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
      Ahhhh, I think I misunderstood some of what you said. The CGI script you are running is working just fine.. but you are saying that every time your CGI script accesses one of the links you would like to check, it's that link which is returning the invalid method headers, not the link you are accessing with your web browser. Hmmm....

      Now we have an interesting question :-) After digging around the docs some, I don't immediatly see anything incorrect about your approach. But if I do, I'll be sure to post it. Sorry about the misunderstanding there :-) Good luck,
      That sure sounds like a permissions issue to me.

      Check the ownership and permissions of the CGI you're trying to reach. Then check the ownership of the script.

      I'll bet one or both of the following is going on: a) the ownership of the script is different from that of the CGI.
      b) their groups are the same, but the CGI's group permissions are set to r--, where they should be r-x.

      After re-reading that, I'm not sure that I've made it totally clear. Feel free to message me if you'd like further explanation.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://92692]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (7)
As of 2018-02-22 17:53 GMT
Find Nodes?
    Voting Booth?
    When it is dark outside I am happiest to see ...

    Results (297 votes). Check out past polls.