CodeIgniter with php5 - CI-generated 404 Error

[eluser]Eric Cope[/eluser]
[quote author="Derek Jones" date="1202068789"]Who is your host, Eric? I'm investing a similar issue where ORIG_PATH_INFO does not contain the correct value when no URI information is included along with the script.[/quote]

Is ORIG_PATH_INFO set by that Apache .htaccess line?

[eluser]Eric Cope[/eluser]
So I did some googling on the topic of ORIG_PATH_INFO. Apparently, there is a bug in PHP when run in CGI mode regarding what is returned in ORIG_PATH_INFO.

My server runs php4 with the server API as apache.
My server runs php5 with the server API as cgi. <- smoking gun???

Derek, can you confirm that the dreamhost problem you are having is running in cgi mode?
http://bugs.php.net/bug.php?id=31843
This bug report is for php4, but I am not sure if it applies to php5 as well...

[eluser]Eric Cope[/eluser]
setting

Code:

$config['uri_protocol']    = "PATH_INFO";

seems to make this work. It sounds like there should be a check for the request to CI's index.php <root>/index.php or <root> at the beginning of Router.php and exit with a blank path before the if statements. What do you think Derek?

[eluser]Derek Jones[/eluser]

That is like my problem, except it is not the entire path, just relative to the web root.

That's the same issue, if you read my active comments to the bug report. Instead of containing only the URI portion following the script, it appears to be including the entire REQUEST_URI / SCRIPT_NAME.

It's actually rather unusual for PATH_INFO to be available on a server that has ORIG_PATH_INFO set. But that change shouldn't matter since PATH_INFO is checked before ORIG_PATH_INFO is. You'll notice that line 76 of URI.php will be equivalent to what changing that config setting run at line 112.

[eluser]etheon[/eluser]
I had the same problem. When migrating to PHP5, the default route seemed to be ignored completely and I always had a 404 error.

However, I fixed it by editing the system/libraries/URI.php file (as much as I loathe editing the core files). Starts roughly at line 91.

Code:

// No QUERY_STRING?... Maybe the ORIG_PATH_INFO variable exists?
$path = (isset($_SERVER['ORIG_PATH_INFO'])) ? $_SERVER['ORIG_PATH_INFO'] : @getenv('ORIG_PATH_INFO');    
if ($path != '' AND $path != '/' AND $path != "/".SELF AND $path != "/index.php/")
{
      $this->uri_string = $path;
      return;
}

Added [$path != "/index.php/"], which was what ORIG_PATH_INFO was giving me (I'm hosted on asmallorange.com for the record).

I figured that, if it did not have to check the default route, it'd use PATH_INFO, which is also set on the server (but gave "/" without any explicit controller and thus was ignored).

[eluser]Derek Jones[/eluser]
etheon, are you using any .htaccess? I have seen what you describe on one other server, but the inclusion of the closing '/' was caused by a .htaccess rewrite, and not a result of ORIG_PATH_INFO including it on a visit to the web root of the domain.

[eluser]etheon[/eluser]
Yeah, I was using the .htaccess fix given in the "CodeIgniter URLs" documentation part.

[eluser]Derek Jones[/eluser]
.htaccess is quite server dependent, so I'd just use it as a starting point. On a server running PHP as an apache module, that rewrite rule will not even trigger as the server correctly assesses that index.php is being requested.

[eluser]etheon[/eluser]
Apparently, on my server, I'd have to put http://hostname/index.php/controller instead of http://hostname/controller without the .htaccess fix. If there is no path given in the URI, then it'll pick index and the default router just fine though.

Anyway, it's fixed now, although I would've preferred not having to tinker with a core library. I just don't understand why it checks for ORIG_PATH_INFO if the PATH_INFO actually exists (albeit it is only "/"). So when _fetch_uri_string() returns a non-empty string (being ORIG_PATH_INFO), the default route is not taken.

[eluser]Derek Jones[/eluser]
Yes, removing the script from the URI will require mod_rewrite, but there are many ways to skin that cat with .htaccess. The user guide's suggestion is not a "fix" so much as one common implementation.

With 1.6.0, incidentally, I believe on the affected servers that if you switch your 'uri_protocol' from 'AUTO' to 'REQUEST_URI' you would not have to maintain a hack to the core.