[#16038] - Invalid HTTP 1.1 Status lines generated by Joomla for 404/500 and maybe more
- Closed
- 15 May 2017
- Medium
- Build: staging
- # 16038
Steps to reproduce the issue
check the headers of a 404 page in Joomla
Expected result
Valid HTTP 1.1 Status line as per https://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html which states
The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code and its associated textual phrase
Therefore:
HTTP/1.1 404 Not Found
Actual result
HTTP/1.1 404
Cache-Control: no-cache
Connection: keep-alive
Content-Type: text/html; charset=UTF-8
Date: Mon, 15 May 2017 17:04:39 GMT
Pragma: no-cache
Server: nginx/1.12.0
Set-Cookie: 2b5a6d72eb04b3ca2060919d2e69f2c9=89t2b6579gogie33tnjpmvdirq; path=/; HttpOnly
Transfer-Encoding: chunked
X-Powered-By: PHP/7.1.5
Other Comments
same happens for 500 errors:
HTTP/1.1 500
instead of
HTTP/1.1 500 Internal Server Error
joomla-cms-bot
- | Labels |
Added:
?
|
||
Look here: https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/application/web.php#L722
// 'status' headers indicate an HTTP status, and need to be handled slightly differently
$this->header('HTTP/1.1 ' . (int) $header['value'], true);
Also see #15738 - see where they DELIBERATELY changed the Unit tests that were failing to suit their new BROKEN implementation of the HTTP 1.1 Status codes!!!
THIS IS NOT WHAT YOU DO WITH UNIT TESTS!!!!
That was actually an unintended side effect of me trying to do fancy stuff with the redirect methods. I also changed the unit test when we reverted back to using the api. Given that everything else didn't have the text I didn't see it as an issue for that pull request. Although it is something we should solve generically
Well however it has been caused, Joomla 3.7.x will soon output invalid HTTP 1.1 status codes as the first output it ever sends to the browser.
Would be easy to fix by extending the use of the $responseMap and using those as the code instead of the int.
I would do the PR but Im on my way out for an indian curry...
if you dump out headers from http://joomla-cms/index.php?option=com_asd
$header['value']in
// 'status' headers indicate an HTTP status, and need to be handled slightly differently
$this->header('HTTP/1.1 ' . (int) $header['value'], true);You get
404 Component not found.
So the fact that casting it to (int) is getting 404 is lucky.. it is very tacky at best!
just for fun i checked drupal and wordpress they also are "wrong" as is myjoomla.com although at least github was correct
drupal
wordpress
myjoomla.com
github
so just cause other projects do the wrong thing so should Joomla?
Just because Joomla USED TO DO THE RIGHT THING it is acceptable to change the unit tests to accept the WRONG THING now for whatever reasons?
its a bug - calm down - its not the end of the world
Its not a bug, Its a regression
Its made Joomla worse than it already was
hardly - but keeping banging your drum
the day any developer writes perfect code we can all go out and get new jobs - until then....
Well Im sorry for demanding that Joomla is held to some kind of standard... shoot me.
The only time Joomla did the right thing was with redirect responses because that one explicitly mapped a status code to a value in an array. Any other way to set the Status header doesn't go through any form of validation, so it hasn't always been right.
So yes it's a regression in that this change was allowed, but no we haven't completely FUBAR'd the handling of that header.
| Title |
|
||||||
| Status | New | ⇒ | Closed | ||||
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-05-15 17:51:47 | ||||
| Closed_By | ⇒ | PhilETaylor | |||||
| Status | Closed | ⇒ | New |
| Closed_Date | 2017-05-15 17:51:47 | ⇒ | |
| Closed_By | PhilETaylor | ⇒ |
It's a valid issue...
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-05-15 18:46:46 |
| Closed_By | ⇒ | rdeutz |
Which Joomla version 3.7.1-rc2?