[daveg]

Hello,

Upon moving servers, I'm finding the following error message generated when trying to run the script (1.73d is installed) on the new server:

POD encountered the following error while trying to run:
500 Can't connect to dmoz.org:80 (Cannot determine protocol)
Attempted retrieval URL: http://dmoz.org/Arts/Celebrities/

I checked settings and ran servertest.pl which passed the test. Permissions are set. I can only assume that some path needs fixing, but not being much or a perl wiz, I figured if I posted the message hear, someone would know just where I should be looking.

I'm *hoping* anyway :-) I know you guys probably look at the error and say "Ah, that means...." whilst I'd parse the files for hours testing and retesting ....

Any leads appreciated...

[daveg]

Update: I just have no idea why it "can't determine protocol"

[splash]

hi daveg,

first, even though i'm a web developer, i actually know very little, but let me see if i can help anyways.

you probably already know that 500 is a server error. so, i went looking for websites that dealt with perl and errors and here is one that i've found:

http://www.perl.com/pub/a/doc/FAQs/c...l-cgi-faq.html

About half way down is this question and answer:

<font color=blue>Q3.4: Why am I getting the "Server: Error 500" message?

You can get a server error for the following reasons:

If the script does not contain the "#!/usr/local/bin/perl" header line that points to the Perl interpreter, or if the path to the interpreter (and/or a library file) is invalid.

If the first line output from the script is not a valid HTTP header (i.e "Content-type: text/html"), or if there is NO blank line after the header data.

If there is a syntax error in your script. Always run it from the command-line first. </font color=blue>

i'm going to keep searching....

good luck!

splash

[daveg]

Hi Splash,

First off, I really do appreciate your taking the time to help here....
Browsing some earlier posts, it seems others have had this problem... yet I've yet to see anyone post that they fixed it nor has anyone solved it for them.

The interesting thing is this: It is not a 500 Internal Server Error.
It is executing the script OK server side but the pod.cgi returns the above error in a nice colorful box. i.e. the script executes serverside but cannot complete it's call to dmoz.org for some reason.

Confusingly, servertest.pl shows no errors.....

I'm right now looking to see if perhaps my new host (aitcom.com) has a required perl module in a less than required version number or something....

[daveg]

OK. I'm dying here. My webhosting company escalated my ticket to the sysadmin who assured me all the proper perl modules are installed. It did pass the servertest.pl, so I believe them.

It is not a temporary problem... it's been days without success. And again, it worked fine before I switched hosts.

Here's the output of the debugging mode, if that's any help. I don't know where else to turn now....

Debugging mode ON

* POD DMoz.Org version: v1.78d
* CGI library version: 2.42
* Perl version: 5.00502
* Server software: Apache/1.3.4 (Unix) PHP/4.0.3pl1
* CGI Revision:CGI/1.1
------------------------------------------------------------------------
Entering: pod_main
Full path details: http://bestcelebritysites.com/cgi-bin/pod.cgi
Entering: pod_read_headers
Leaving: pod_read_headers
Entering pod_get_first_page
Parsed URL: http://dmoz.org/Arts
------------------------------------------------------------------------
URL fetching: http://dmoz.org/Arts
Getting...
------------------------------------------------------------------------
Leaving: pod_get_first_page
Entering: pod_output
Expires: Thu, 02 Aug 2001 05:34:52 GMT Date: Wed, 01 Aug 2001 05:34:52 GMT Pod-version: v1.78d Content-length: 14051 Mime-version: 1.0 Content-Type: text/html

POD encountered the following error while trying to run:
500 Can't connect to dmoz.org:80 (Cannot determine protocol)
Attempted retrieval URL: http://dmoz.org/Arts

[splash]

daveg,

is it just that URL? (http://dmoz.org/Arts)

splash

[daveg]

Nope

It's the whole directory...

i.e.
http://bestcelebritysites.com/cgi-bin/pod.cgi
http://bestcelebritysites.com/cgi-bin/pod.cgi/Arts
http://bestcelebritysites.com/cgi-bi...ts/Celebrities

etc. The site is live so you can see exactly what I'm getting by clicking those links....

:-(

Thanks for the help.

[splash]

does this make any sense?

http://listserv.activestate.com/pipe...ly/000757.html

does Dell host your site? this one's for "fun":
http://www.dellhost.com/us/en/host/f...oubleshoot.htm

splash

[daveg]

Not what's going on here, unfortunately.

The thing is, the script executes to the degree that I'm not getting an Internal Server Error. It loads the header and footer as it should. But where the data itself should be is the "Can't connect to htto://dmoz.org:80..." error.

I'm hosting with AITcom.

[DocJohn]

Can you log into your server from the command line?

If so, try these two things...

1. Try connecting to http://dmoz.org:80 via lynx, a text-based Web browser often installed on unix systems. Type in:

lynx http://dmoz.org:80

and see if that connects. If it doesn't (and you do have lynx), then the problem is an issue of connectivity between your server and dmoz.org. That's a sysadmin problem.

2. Try typing in:

traceroute dmoz.org
or
/usr/sbin/traceroute dmoz.org

Again, this will tell you whether your server can find dmoz.org.

If both of these things work, then it becomes more of a mystery to me and a crap-shoot in trying to solve the problem. Try using "www.dmoz.org" instead of just plain dmoz.org. E-mail me privately and maybe I can help further.

John

[daveg]

Well, I am not allowed to telnet into my server without supplying the hosting company with my bank details (!), so I called tech support and started with that.

It didn't turn out to be the problem, however - after hours of brainstorming with techs, the problem has been solved. When admins and tech support people keep coming back to you saying that it's X or Y and not their problem, and you know it's not X *or* Y, just keep brainstorming until an answer is found :-) (It was broken for ~ 2 weeks)

As it turned out (and I'm paraphrasing the admin, so my tech-speak(TM) may not be 100% accurate), the problem was that the host could not properly use IO::Socket with the scripts.

It appears the libm series libraries were not compatible with my server's version of the /etc/protocols file. They updated the file and added the correct libraries and the script now seems to be functioning properly.

Whee! :-) Hope anyone else with this problem discovers this thread :-) Thanks splash and DocJohn for the help :-) And DocJohn -- thanks for the script! :-)

[splash]

Yay! All right! Woo Hoo!!

You know, what you say about support (aka help desk) or others (in my case, the database people at work) saying that "it's not their problem" and that it's someone else's problem seems to be very true.

we have this data person at work who constantly tells us "it's the code, not the data" that we have to laugh or we'll go nuts! we usually have to hunt down their error and even tell them how to fix it, not because they can't do it, but because they don't think it's their problem!

i'm glad it's fixed.

splash