#2524 - Re-review HTTP status codes wrt IE and IIS
-
By Chris Graham
- Added
- 1 view
| Identifier | #2524 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Re-review HTTP status codes wrt IE and IIS |
| Status | Open |
| Tags |
Roadmap: Over the horizon (custom) Type: Standards compliance (custom) |
| Handling member | Deleted |
| Addon | core |
| Description | We have this line of code limiting when we send out accurate HTTP status codes:
if ((!headers_sent()) && (function_exists('browser_matches')) && (!browser_matches('ie')) && (strpos(cms_srv('SERVER_SOFTWARE'), 'IIS') === false)) { The reason is that... 1) IE has traditionally replaced our HTTP output with inbuilt error messages for particular HTTP statuses. I'm not sure if it does still - if not, we should make a change. 2) IIS has done similar, replacing our HTTP output with its own inbuilt error message in such a case, as it considered "CGI to have failed". Again, I'm not sure what IIS does nowadays, and we should review our base-line. tut_web_hosting should be updated. Regardless of the above we should probably make a new config option to work here. We can't trust that various kinds of proxies and web servers may mess with output when HTTP status codes are set. |
| Steps to reproduce | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
And, IIS is still "helping" by messing with what is displayed:
http://www.iis.net/learn/application-frameworks/install-and-configure-php-on-iis/improve-php-error-messages-in-iis-7-and-above
So I suggest we add a config option with 3 possible values:
- Always use correct HTTP status codes to guarantee correct semantics (defaults to on on non-IIS)
- Always use 200 success status code to avoid middleware interference (defaults to on on IIS)
- Use correct HTTP status codes except on Microsoft web browsers which interfere with display