website issues

[safemode]

It appears that VS's website is experiencing some major issues with handing php responses. Other sourceforge sites dont seem to be experiencing this but i dont know if any use php as extensively as VS does. PhP files will sometimes ask to be downloaded rather than rendered, blank pages. Usually refreshing a few times fixes it. It happens all over the site on multiple browsers and OS's.

[pheldens]

It appears that VS's website is experiencing some major issues with handing php responses. Other sourceforge sites dont seem to be experiencing this but i dont know if any use php as extensively as VS does. PhP files will sometimes ask to be downloaded rather than rendered, blank pages. Usually refreshing a few times fixes it. It happens all over the site on multiple browsers and OS's.

I experience exactly that

the webserver mimes are configged wrong, but it behaves very erratic, probably depending on load of somekind.

[ace123]

I added
AddType application/x-httpd-php .php
to the .htaccess... I'm going to see if that lessens the frequency of this problem.

[Miramor]

I'm still seeing it.

I saw this problem once before on another forum, and it turned out their host had some servers screwing up and didn't feel like fixing the problem... I'm a little shady on the details, but they had to switch to a different host.

(Also lost all their old content, but that wasn't because of hardware failures; the old host just wouldn't give them access to it unless a fee was paid, and the admin decided to give them the finger and start over again instead.)

[pheldens]

it has php mime defined too often, on the webserver, maybe it gets included multiple times?

it cycles from
x-http-php
x-http-php3
x-http-php4

etc.. untill it hits the proper one.

it has worsened it sooner

you should remove all php related rules from your .htaccess

this should be configged at the sitewide cfg properly..

this is a security risk btw!

[pheldens]

hmmm I wasnt able to download config.php, or rather I was able to download it, but it contained the rendered page content (empty)
so the code does get executed by mod_php atleast.
I think something is rewriting headers then?

[pheldens]

http://httpd.apache.org/docs/2.0/mod/co ... #forcetype

put that in your /forums/.htaccess

[ace123]

ForceType isn't the problem. I can see that the buggy pages are all being sent with the application/x-httpd-php mimetype.

I'm going to try some addhandler's.... I still don't understand what is going on when that happens. It seems that it should be giving a 500 error if mod_php isn't available since we use php_value directives in the .htaccess.

[ace123]

This is a problem with sourceforge's Apache PHP module on one of their servers. I tried putting a syntax error in, and it worked 100% of the time. Add in any other code, even blank and that error happened.

Anyway, I found that they have a PHP cgi binary at /usr/bin/php.
I made a simple CGI script to wrap around the PHP executable.

Code: Select all

#!/bin/sh

exec /usr/bin/php $*

(Actually I added that one just now since it wouldn't let me POST without it.

in addition to a handler:

Code: Select all

AddHandler myphpfile .php
Action myphpfile /cgi-bin/php-exec.cgi
Action application/x-httpd-php3 /cgi-bin/php-exec.cgi
Action application/x-httpd-php4 /cgi-bin/php-exec.cgi
Action application/x-httpd-php /cgi-bin/php-exec.cgi

And I don't see the problem as much any more (not at all so far).

Seems like a waste of resources but until sourceforge fixes their problem I guess we are using CGI.
Almost as bad as the combination of CGI scripts I hacked together to workaround the lack of Cron scripting. Sourceforge's servers are just getting worse and worse.

[ace123]

whoops... you can't POST any more now.

EDIT: So I added a <Limit GET> around the CGI module.

If you post a topic you will have to hit refresh maybe once if you are unlucky.

I could probably figure it out with another few hours. Maybe later on if it bugs enough people.

Status update:
I'm now using mod_rewrite. Almost down to the last trick in the book, but I think this one will work finally!
Just need to rewrite the URL

...

[ace123]

I think it finally works!
YAY!

Sorry about the downtime, but hopefully it was worth it.

EDIT: another test. I added a QUERY_STRING parameter for debugging.
And it's all thanks to mod_rewrite and CGI.

Hopefully no more problems. But I'm sure there will be more.

Final .htaccess:

Code: Select all

RewriteEngine On
RewriteRule ^(.*)\.php$ /cgi-bin/php-exec.cgi/$1

Final /cgi-bin/php-exec.cgi:

Code: Select all

export PATH_INFO="$REDIRECT_URL"
export SCRIPT_URI="$REDIRECT_SCRIPT_URI"
export SCRIPT_URL="$REDIRECT_URL"
export REQUEST_URI="$REDIRECT_URL?$REDIRECT_QUERY_STRING"
export QUERY_STRING="$REDIRECT_QUERY_STRING"

export DOCUMENT_ROOT=/home/groups/v/ve/vegastrike/htdocs
export PATH_TRANSLATED="$DOCUMENT_ROOT$PATH_INFO"

exec /usr/bin/php $* 2>&1

As to those exports, PHP wasn't exactly designed to be run as mod_rewrite'ed CGI script.... but those variables allow me to trick PHP into thinking it's being run directly.

Apparently the AddHandler and Action commands do not pass POST data (which is stupid), yet mod_rewrite does.
I've lost count of the number of configuration nuisances on these servers.

[safemode]

sweet deal. pain in the name of vs.

[loki1950]

Thx ace123 haven't had a blank tab yet this morning

Enjoy the Choice

[www2]

I dont can acces the wiki 404.

[loki1950]

Not a 404 but the Opps page for me.

Enjoy the Choice

[www2]

that is the 404

[ace123]

Fixed... I had commented out the mod_rewrite line to translate /wiki/Something to mediawiki.

I was worried it was a bigger problem than a missing htaccess rule.

[pheldens]

for me it works perfect now, thanks.