It seems that DreamHost has disabled this option. What is it? Good question. From the online PHP manual,

This option enables the URL-aware fopen wrappers that enable accessing URL object like files. Default wrappers are provided for the access of remote files using the ftp or http protocol, some extensions like zlib may register additional wrappers.

What are the security issues with allowing url’s to be openable in a PHP script? Well some of them are pretty hair raising and there’s a excellent overview of the problems with allowing urls to be opened in PHP programs. So that’s all well and good. I appreciate the fact that DreamHost takes steps to put together a secure hosting system.

And as a side note, my hair’s still standing on end with the way PHP allows some of this stuff. Granted, you get security issues in Perl, especially if you’re going to shovel userinput through system calls, or even sometimes just blatting stuff into email messages. But there’s convenient utilities to sanitize such input, plus judicous ways to call the system function to foil such attacks. But this url thing, especially the way it can be used to trick a site into including and running a remote file… The one that really blows my wig back is where the file name is garnered from the GET url, so that you could change, just by typing on your own browser to attack, http://example.com?goodfile.php to http://example.com?badfile.php and just sit back and watch the mayhem unfold.

Goodness gracious.

But let’s zoom back to that DreamHost Wiki document for a second. Reading through it, one gets the impression that include is on the no-no list. Oh, and require is mentioned at the very last moment too. At a guess, I’d say fopen was also verboten, though that’s not mentioned here. So we’re left with a bit of mystery as far as the process of de-allow_url_fopen-ing goes.

Codesnippet is one of the plugins that’s creating my mysterious error message, so I grep thru all of its files for instances of the include or require calls. I don’t find either, but I do find require_once and at a guess, I’d say it’s on the shit list too. Hmmm.

So I google for more info on allow_url_fopen and it’s astonishing how little info there is.

OK, let’s recap. Basically, you can’t specify url’s to a set of functions that take url’s as arguments. So far I have: include, require, include_once, require_once, and fopen.

One method for bypassing the problem is to specify the file in such a way it’s no longer an url. The important thing to remember is that this property holds in a case like this:

require_once('/home/coolblog/www.urlname.com/blog/wp-config.php');


If you can connect to blog with http://urlname.com/blog/), then it’s a url, even though you don’t have the http prefix. As DreamHost’s Wiki entry notes, you can fix the problem like this:

require_once($_SERVER['DOCUMENT_ROOT'].'/blog/wp-config.php');


But there are more complex cases out there, that require cURL to solve. Wandering over to that page we immediately notice this example

<?php
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "http://example.com/");
curl_setopt($ch, CURLOPT_HEADER, 0);
c u r l _ e x e c($ch);
curl_close($ch);

given for fetching a web page. Also, there appear to be some new candidates for the “shit list” here: file_get_contents(), and file(). Is this list complete? I don’t know for sure. CURL, Client URL Library Functions is actually a pretty interesting wrapper, especially if you scroll down the page and peruse the commentary.

As a postscript, in case you were wondering why c u r l _ e x e c was written that way, well so am I. If I don’t break it up, I can’t save this post! I’m guessing some kind of hyperactive filter checking for cruft in here? Even though it’s not going to be executed here, etc. It took me quite some time to figure out what was going on, the message I kept getting was

Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

So I saved off the file locally and left it alone for the rest of the night, even though I couldn’t find anything in the status logs. But later on, I wound up creating a new post, and then, believing that all was well, returned to this post and got stonewalled again…So I went back and put in one line at a time to find out where the problem was…Aiee…

In any case, I have some questions into Dreamhost I’m waiting on, so I’ll go ahead and publish this. But I’d like to get together sort of a conversion kit that’s a bit more comprehensive than the information I found.