Resolved Bug


This bug has been marked as resolved.

Pretty URL's with FastCGI and 404's

Permalink 0 0 Browser Info Environment
When using FastCGI for PHP it seems that the default .htaccess file does not work. Rather then being:

RewriteRule ^(.*)$ index.php/$1 [L]

That line should be:

RewriteRule ^(.*)$ index.php?/$1 [L]

However, even though that makes the rules in the .htaccess work the software is not picking up the correct page, since FastCGI is not setting PATH_INFO or the related variables. For hosts which do not set this information a workaround is needed.

I was able to put together a patch which adds the needed question mark to the .htaccess as well as getting the correct path into the system - getting around the missing PATH_INFO for those using FastCGI.

Patch is attached and has been verified to work for several clients.

-JJ Galvez
1 Attachment

Tags:

pretty URLs, 404
Status: Resolved
View Replies:
Remo replied on at Permalink
Remo
I don't think this is a general FastCGI problem. I was able to use PATH_INFO with both Nginx and Apache (both FastCGI)

Not that it changes anything, just to mention that FastCGI can work.

It might be nice to have an alternative to PATH_INFO because as you wrote, it doesn't always work.
jgalvez replied on at Permalink 1 Attachment
I believe you're right in that it isn't a general FastCGI problem. However here is what I'm seeing, first the .htaccess issue:

Apache 2.2.x (.16 in my case) w/ FastCGI displays an error when enabling pretty url's and accessing a page other then the index. Adding the ? corrects this and enables the server to return a response.

The problem with the response in this case is that it always returns the same content as the index. This is due to the missing PATH_INFO data and the patch adds the ability to use argv to replicate that data when it isn't being set.

Switching from FastCGI to CGI will fix this, but I'd rather run under FastCGI for performance reasons.

I've applied this patch to various clients and it's worked flawlessly, but even if we forget about the .htaccess portion of this patch it would be a good idea to use the alternative method of creating the PATH_INFO data.

A modified patch with only the PATH_INFO alternative has been submitted with this message.
Mnkras replied on at Permalink
Mnkras
I believe this is fixed in the svn
Mnkras replied on at Permalink
Mnkras
Fixed in the next version of concrete5 closing this

concrete5 Environment Information

# concrete5 Version
5.4.1.1

# concrete5 Packages
None

# concrete5 Overrides
None

# Server Software
Apache

# Server API
cgi-fcgi

# PHP Version
5.2.15

# PHP Extensions
APD, bcmath, calendar, cgi-fcgi, ctype, curl, date, dom, exif, filter, ftp, gd, gettext, hash, iconv, imap, json, libxml, mbstring, mcrypt, memcache, memcached, mhash, mysql, mysqli, openssl, pcntl, pcre, PDO, pdo_mysql, pdo_sqlite, posix, pspell, Reflection, session, SimpleXML, sockets, SPL, SQLite, ssh2, standard, tokenizer, XCache, xml, xmlreader, xmlrpc, xmlwriter, xsl, Zend Optimizer, zlib.

# PHP Settings
log_errors_max_len - 1024
max_execution_time - 5
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 60
memory_limit - 300M
post_max_size - 100M
safe_mode - Off
safe_mode_exec_dir - <i>no value</i>
safe_mode_gid - Off
safe_mode_include_dir - <i>no value</i>
sql.safe_mode - Off
upload_max_filesize - 100M
memcache.max_failover_attempts - 20
mysql.max_links - Unlimited
mysql.max_persistent - Unlimited
mysqli.max_links - Unlimited
pcre.backtrack_limit - 100000
pcre.recursion_limit - 100000
session.cache_limiter - nocache
session.gc_maxlifetime - 7200
safe_mode_allowed_env_vars - PHP_
safe_mode_protected_env_vars - LD_LIBRARY_PATH
xcache.var_maxttl - 0

Browser User-Agent String

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.45 Safari/534.13