I have Drupal (4.7.3) installed on a Dreamhost server (PHP 5 as Fast CGI). When I have the 'Site Maintenence' enabled to have my site offline, it returns a '503 OK' header instead of '503 Service unavailable'. In the drupal_set_header function, headers that are sent in the format 'HTTP/1.x [Code] [Message]' need to be translated to 'Status: [Code] [Message]'. I'm not sure how Drupal could determine when this needs to be done, but I've included the path that I had to change in my Drupals common.inc file.

CommentFileSizeAuthor
#4 patch_25.txt610 bytesdave reid
#3 patch_24.txt608 bytesdave reid
patch_23.txt497 bytesdave reid

Comments

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Version: 4.7.3 » x.y.z
drumm’s picture

drumm
he/him
Location NY, US
commented
Status: Needs review » Needs work

This will have to be revised to check how PHP is running.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Status: Needs work » Needs review
StatusFileSize
new patch_24.txt608 bytes

I found what code is needed to determine if PHP is running as CGI. Uploaded the revised patch.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
StatusFileSize
new patch_25.txt610 bytes

Fixed logic error in patch

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Assigned: Unassigned » dave reid
dries’s picture

dries commented

I don't understand, and the code comment isn't sufficient:
+ // If PHP is running as CGI, certain headers need to be translated

Why? What is the underlying technical reason?

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

As described in the initial bug description, when PHP is running as CGI and you try and send header('HTTP/1.1 503 Service Unavailable') or similar header, the actual result is a '503 OK' header in the browser. I'm pretty sure it's a bug in the PHP/CGI interface. Those kind of headers (HTTP/1.x [code] [description]) need to be sent as header('Status: [code] [description]').

Crell’s picture

Crell commented

Maybe I'm missing something, but why would you want to run PHP as CGI for something as large as Drupal in the first place? mod_php is far faster and better maintained.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

Actually I'm running my website with PHP 5 and Fast CGI. It runs just as fast as mod_php and for my webhost (Dreamhost) it's pretty much required for large php applications. They have a pretty secure and fast setup on their servers, so it's not a speed issue.

gerhard killesreiter’s picture

gerhard killesreiter commented

I can reproduce the problem on my fast-cgi install. Can't say I terribly like the patch though.

dries’s picture

dries commented

What do you mean with 'a bug in the PHP/CGI interface'? Shouldn't that be reported against PHP then?

Crell: http://buytaert.net/drupal-webserver-configurations-compared

Kjartan’s picture

Kjartan commented
Status: Needs review » Closed (won't fix)

Marking at won't fix.

a) It is a bug in PHP not Drupal.
b) Clients should be using the Status-Code and not the Reason-Phrase to make judgements.

The patch would just add complexity for no real gain. And should a lot of clients missbehave and go by the Reason-Phrase, this only matters for the maintenence screen which should be a pretty rare occurance.