View Issue Details

IDProjectCategoryView StatusLast Update
0002524Composrcorepublic2019-11-14 22:03
ReporterChris GrahamAssigned To 
Severityfeature 
Status non-assignedResolutionopen 
Product Version 
Fixed in Version 
Summary0002524: Re-review HTTP status codes wrt IE and IIS
DescriptionWe 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.
TagsRoadmap: v12, Type: Standards compliance
Attach Tags
Time estimation (hours)1
Sponsorship open

Activities

Chris Graham

2016-04-27 21:45

administrator   ~0003818

Ok I've done some checks, and even Microsoft Edge has the "friendly error messages" feature. It only happens if there are fewer than 512 bytes in the response, but that's really annoying when debugging.

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

Issue History

Date Modified Username Field Change
2016-04-27 14:48 Chris Graham New Issue
2016-04-27 21:45 Chris Graham Note Added: 0003818
2017-05-01 16:11 Chris Graham Tag Attached: Type: Standards compliance
2019-11-14 21:52 Chris Graham Tag Attached: Roadmap: v12