Posted by Dave Reid on August 31, 2006 at 8:00pm
6 followers
| Project: | Drupal core |
| Version: | x.y.z |
| Component: | base system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Dave Reid |
| Status: | closed (won't fix) |
Issue Summary
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.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| patch_23.txt | 497 bytes | Ignored: Check issue status. | None | None |
Comments
#1
#2
This will have to be revised to check how PHP is running.
#3
I found what code is needed to determine if PHP is running as CGI. Uploaded the revised patch.
#4
Fixed logic error in patch
#5
#6
I don't understand, and the code comment isn't sufficient:
+ // If PHP is running as CGI, certain headers need to be translatedWhy? What is the underlying technical reason?
#7
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]').
#8
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.
#9
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.
#10
I can reproduce the problem on my fast-cgi install. Can't say I terribly like the patch though.
#11
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
#12
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.