Jump to content

Trouble grabbing file...


grogers

Recommended Posts

I'm new to the PHP world and trying to work my way through a problem.  I've gone down many roads, but can't seem to find the answer.  I'm not even sure this is so much a PHP question at this point as a host configuration issue.

 

I'm trying to grab an XML file from a remote server.

 

My first try was to try to shell out a wget as follows:

 

  exec("wget -q -O status.xml - http://$username:$password@$hostname:$port/cgi-bin/status.xml",$xmlget,$err);

 

This didn't work.  Not a surprise since doing it directly from SSH gave:

 

  Connecting to mydomain.com|99.99.99.99|:8080... failed: Connection refused.

 

[Note that the port 8080 above is, I think, key]

 

I've since tried method using both file_get_contents and cURL.  Similar results for all.  I won't clutter this up with the code unless you ask.  It's all very straightforward.  [file_get_contents complains 'Connection refused' and curl_error says 'couldn't connect to host'].

 

With all of the methods, I'm able to grab, say, google.com AND a page from mydomain.com (default port 80), just not from port 8080.

 

I've set 'allow_url_fopen = on' in php.ini and in my code for good measure.

 

Also, the XML file that lives at 8080 is retrieved fine through a browser.

 

I'm hosted at GoDaddy on their "deluxe shared linux" plan.

 

Is there something obvious I'm missing that would allow all this to work over port 80, but not 8080?

 

Thanks is advance!

 

Greg

Link to comment
Share on other sites

If the file is being returned from a script it could be that there are things going on that aren't obvious like redirects.  Have you tried watching what is going on using firebug or similar tool? Is it setting any cookies, that might be required, perhaps for a session?  There could also be a check for user agent?  With curl you can make your server act as if it was a browser and support any of those requirements.

Link to comment
Share on other sites

The file I'm trying to grab is just sitting out there, no scripts, etc.

 

I tried the user_agent approach with cURL but got the same results.

 

I found this blurb on php.net:

 

On Centos 5, and maybe other Red Hat based systems, any attempt to use file_get_contents to access a URL on an http  port other than 80 (e.g. "http://www.example.com:8040/page") may fail with a permissions violation (error 13) unless the box you are running php on has its seLinux set to 'permissive' not 'enforcing' . Otherwise the request doesn't even get out of the box, i.e. the permissions violation is generated locally by seLinux.

 

I don't believe this applies to GoDaddy hosts, but I'm really not sure.  I have a note in to their support.

Link to comment
Share on other sites

For what it's worth, this does seem to be a problem with my particular host (GoDaddy) and allowing outgoing file requests (through just about any method) to ports other than port 80.  I moved the service from which I was trying to get the XML from port 8080 to port 80 to test and everything works fine.

Link to comment
Share on other sites

Ahh, probably I should have suggested you try telnet.  That's probably the best way to verify that you don't have a socket level issue.  I have had nothing but problems with selinux and lamp servers,  and I always disable it.

 

If it is indeed turned on, then I'd suggest disabling it and doing a quick test to see if your script works ok against port 8080.  Disabling all outbound client connections to any port other than port 80 is ridiculous behavior, and not something you ought to have to work around.

 

This blog post covers what you need to know:  http://tweakandtune.blogspot.com/2009/03/centos-disable-selinux.html

 

 

 

 

 

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.