lighttpd/1.4.22 does not populate _REQUEST['action'] for wp-login.php

[myrond]

lighttpd/1.4.22 does not populate _REQUESTaction? for wp-login.php, this in turn disabled any action in the switch statement breaking the ability to logout.

Symtoms of this bug are: clicking logout in wordpress 2.8 and going to the login page but not really logging out. Clicking logout in wordpress 2.3 and being redirected right back to the /wp-admin page.

adding this code to wp-login.php, fixes the behavior and re-enables all features in wp-login.php.

I don't know the wordpress code but if there is a section which deals with idiosyncrasies of web servers that lighttpd be detected and this code be run to deal with it.

Main

if (strpos($_SERVERSERVER_SOFTWARE?, 'lighttpd') !== false)
{
$_lighty_url = $base_url.$_SERVERREQUEST_URI?;
$_lighty_url = @parse_url($_lighty_url);
$_SERVERQUERY_STRING? = $_lighty_urlquery?;
parse_str($_lighty_urlquery?, $_lighty_query);
foreach ($_lighty_query as $key => $val)
$_GET[$key] = $_REQUEST[$key] = $val;
}

[myrond]

oops ... this comment should be formatted a bit better

//
// Main
//


if (strpos($_SERVER['SERVER_SOFTWARE'], 'lighttpd') !== false)
{
$_lighty_url = $base_url.$_SERVER['REQUEST_URI'];
$_lighty_url = @parse_url($_lighty_url);
$_SERVER['QUERY_STRING'] = $_lighty_url['query'];
parse_str($_lighty_url['query'], $_lighty_query);
foreach ($_lighty_query as $key => $val)
$_GET[$key] = $_REQUEST[$key] = $val;
}

[dd32]

What version are you testing under?

What superglobal is lighttpd not setting? ($_REQUEST or $_GET? how about $_POST?)

Should WordPress work around a major bug in Lighttpd+PHP which renders 90% of web apps not useable? (given previous stables have obviously worked)

[myrond]

I have tested the following wordpress releases:
2.8.0
2.3

I have tested the following lighttpd releases 1.4.19,1.4.20,1.4.22 all of them exhibit the same behavior with both listed wordpress combinations.

2.3 will simply bounce you back to the login base, with 2.8 it has a default switch which will ask you for a login (even though the cookie was not deleted)

Both _REQUEST and _GET are not populated and they are empty; and the workaround I've posted has been applied to numerous web applications which have problems and need that data. (drupal, magento, others).

However upon further research it appears this problem only occurs on sites which are using lighttpd rewrite rules.

namely:

url.rewrite-once = (
"^/(.*\.php)" => "$0", #(this line grabs the wp-login.php so it won't be grabbed by 
"^/(.*)$" => "/index.php/$1" #this line
)

This is a common rewrite used on lighttpd boxes, and the rewrite appears to strip _REQUEST. Much apologies please disregard this or apply it (makes no difference).

I suspect that anyone else who is using rewrite rules will apply a fix similar to the one I have listed. all of the wp-admin stuff are excluded by a previous (non listed rule) and as such do not have problems with the _REQUEST variable.

[dd32]

My opinion here is that the rewrite rules either need to be more complex, or Lighttpd needs to include a work-around which works for it..

Something like this doesnt work?

"^/(.*\.php.*)$" => "$0"

Suggesting that if the rewrite rule above doesnt work, then those affected should use the suggested patch in their wp-config.php file.. Someone can just add it as a note to the lighttpd install reference maybe.

[miqrogroove]

I didn't see anything in this thread to suggest it was a problem beyond the PHP itself. Please reopen with affected PHP version numbers if needed.

[myrond]

I never said it was a bug in wordpress, the bug is in PHP/lighttpd, but there is a simple fix to work around it in wordpress:

if (strpos($_SERVERSERVER_SOFTWARE?, 'lighttpd') !== false)
{
$_lighty_url = $base_url.$_SERVERREQUEST_URI?;
$_lighty_url = @parse_url($_lighty_url);
$_SERVERQUERY_STRING? = $_lighty_urlquery?;
parse_str($_lighty_urlquery?, $_lighty_query);
foreach ($_lighty_query as $key => $val)
$_GET[$key] = $_REQUEST[$key] = $val;
}

apply that to wordpress and it fixes the problem. I was hoping more than anything if other people run into this problem google will pick it up and they will be redirected to a workaround which can be applied to wordpress.

Hopefully someday lighttpd/php will be patched and it will work. If this was applied to wordpress core that is fine too.

[nacin]

We can possibly add that logic to wp_fix_server_vars().

[miqrogroove]

myrond, thanks for the follow up. Could you please tell us which PHP version is affected by this problem?

[myrond]

Every version of PHP I tried actually; I think the bug is actually in lighttpd (I've tried all versions from 1.4.19-1.4.22) I tried this on several pieces of hardware on gentoo/ubuntu and debian both stable and unstable and all of them exhibited this behavior.

As soon as I disabled the rewrite rules _GET became populated, and everything started working.

Thankfully I applied the fix I mentioned earlier and everything has gone smoothly for a long time.

Rewrite rules currently applied as follows

url.rewrite-once = (
"^/(wiki|wp-admin|wp-includes|wp-content|storage)/(.*)" => "$0",
"^/wp-admin$" => "$0",
"^/(sitemap\.xml|sitemap\.xml\.gz)" => "$0",
"^/(.*\.php)" => "$0",
"^/(.*)$" => "/index.php/$1"
)

php versions that I am running that exhibit this bug with lighttpd (bug AGAIN I believe it is the interaction between lighttpd rewrite and the backend fastCGI process as bug goes away as soon as I disable the rewrites), this bug may exist in fastCGI with perl/python or other languages as well in its interaction with lighttpd's mod_rewrite.

PHP 5.2.6-1+lenny3 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 26 2009 22:16:23)
PHP 5.2.6-1+lenny4 with Suhosin-Patch 0.9.6.2 (cli) (built: Nov 22 2009 02:38:03)
PHP 5.2.8-pl2-gentoo with Suhosin-Patch 0.9.6.3 (cli) (built: Mar 22 2009 19:50:39)
PHP 5.2.9-pl2-gentoo with Suhosin-Patch 0.9.7 (cli) (built: Apr 23 2009 16:27:40)

(sorry if I haven't updated in a while!!)

[miqrogroove]

Do you have Suhosin enabled? If so, could you re-test with Suhosin completely disabled or in simulation mode?

[myrond]

Those are my current machines. I turned suhosin off to test and it made no difference. Actually the first machine I ran into this on did not have suhosin compiled or linked in at all.

[miqrogroove]

Okay well the next logical step is to point out the php.net resources. Are there any known issues over there? They probably have some experienced people who know whether this is a bad server module or some kind of bug in PHP itself. Have you done any searches in bugs.php.net or created any tickets in there yet?

[miqrogroove]

#11723 duplicates this issue

[myrond]

I don't believe that the problem is with php, but rather lighttpd; I ran wordpress just fine migrating from apache/php and also ran litespeed just fine as well. I only ran into this problem when I implemented the rewrite rules under lighttpd.

I found a easy fix to apply which solved my problem; additionally I found other content management systems which have had similar problems with lighttpd and have implemented a work-around in their code.

It has been six months since I found this problem installed the workaround and I forgot a ticket even existed on this!

I just wanted to post this to wordpress w/ fix in case other people had the same problem. I realize lighttpd occupies a fairly small nitch and it took me a decent amount of time testing and figuring out what was going on; maybe just maybe by posting this on the internet I can potentially save someone else a lot of time in redeveloping a solution to this little problem (or giving up).

[danielsummers]

I've run into this in a different context, but found this with my searches. I do have several WordPress blogs. I'm looking to move to lighttpd to ease the burden on my server.

That being said, this is how I implemented it...

		if (strpos($_SERVER["SERVER_SOFTWARE"], "lighttpd") !== false) {
			parse_str(parse_url($_SERVER["REQUEST_URI"], PHP_URL_QUERY), $_GET);
		}

Passing the PHP_URL_QUERY parameter to parse_url only returns the query string portion; parse_str can put the items straight into $_GET, so you don't need the interim array and for loop.

(Please correct me if I'm wrong; I'm just ecstatic to have found the solution. In lighttpd's documentation, WAY at the bottom, it shows how to pass the query string; however, I've implemented the above in my web app so I can use the syntax I'm used to.)

[danielsummers]

Meant to include the link to the docs... Sorry for the second update.
​lighttpd's mod_rewrite documentation

[danielsummers]

One more - the easiest way to configure WordPress with lighttpd is to set index.php as the 404 handler. The configuration directive

server.error-handler-404 = "/index.php"

can be placed into the configuration, and query strings ARE passed properly with this technique. Lighttpd doesn't send a 404 header, so it's up to the theme's 404.php file to send that header. Maybe this could go in a FAQ.

[nacin]

We need a proper patch here, but it's enough to mark it for needing testing.

[c3mdigital]

#20008 was marked as a duplicate.

[chriscct7]

Closing as wontfix. Complete lack of interest on the ticket over the last 5 years, and no additional reports. Feel free to reopen when more interest re-emerges (particularly if there's a patch)