Bug #22529
closed
stat_apache always logs HTTP status 200
Added by Felix Nagel about 14 years ago. Updated over 9 years ago.
0%
Description
Method statistic always logs a HTTP status "200" OK when logging in Apache style (config.stat_apache = 1), even when a 404 Status is thrown by TYPO3 (by using pageNotFound_handling and pageNotFound_handling_statheader).
Hardcoded in file typo3\sysext\cms\tslib\class.tslib_fe.php within the function statistics() in line 3796.
This is also a problem for extensions like ics_awstats.
(issue imported from #M14225)
Updated by Felix Nagel about 14 years ago
I'm not sure how to do this.
Is there any way to recognize the already set status header? I tried headers_sent() and headers_list() with no success.
Perhaps it would be suitable to add a var to $this->config['stat_vars'] holding the header status.
Updated by Chris topher over 13 years ago
I just experienced this problem....
Can't you read out the header from where it is made, meaning from the function where the value of $TYPO3_CONF_VARS['FE']['pageNotFound_handling'] and $TYPO3_CONF_VARS['FE']['pageNotFound_handling_statheader'] are evaluated?
Updated by Felix Nagel over 13 years ago
You thought about reading the status code after it was sent and than use it? I tried this and failed. Take a look above to see what PHP functions Ive sued to reach this approve.
Updated by Chris topher over 13 years ago
Yes, that's what I thought.
I just tried with headers_sent() and apache_response_headers() in the function statistics(). They contain many things, but not the HTTP statuscode.
But this code is given out correctly, so it must be there at same place.
But how can one get it?!
Updated by Felix Nagel about 13 years ago
It seems this could be done by using a user function as pageNotFound_handling and a patched statistics() function (now line 3735).
Register the header status as GLOBALS could be an approach, see http://bugs.typo3.org/view.php?id=16566
I will give it a try soon.
Updated by Felix Nagel about 13 years ago
Ok, now I'm sure there's no way to catch the already sent status code: http://bugs.php.net/bug.php?id=52555
Ive Xclassed the tslib_fe: sadly Im running into problems passing the status from pageNotFoundAndExit (which handles all errors like 404, 403, etc) to the statistics function. I've tried different ways but failed. Any idea how to pass the var?
Im able to post a test extension here, if somebody would like to give it a try.
Updated by Alexander Opitz almost 11 years ago
- Category deleted (
Communication) - Status changed from New to Needs Feedback
- Target version deleted (
0)
As this report is very old, is the handling in newer TYPO3 CMS Versions (like 6.0/6.1) more like you expect it?
Updated by Felix Nagel almost 11 years ago
This is nothing to "expect". We're sending non 200 status code but always log 200. It's a bug.
I searched trough 6.0.x but was not able to find any of the stats configs. Has this feature been removed in 6.x?
I am sure its not fixed in latest 4.7.x.
Please do not close just because its old.
Updated by Riccardo De Contardi almost 11 years ago
config.stat_mysql and config.stat_apache have been removed in TYPO3 6.0
Updated by Felix Nagel almost 11 years ago
Including config.stat? If so this ticket could be set to 4.x only
Updated by Chris topher almost 11 years ago
- Status changed from Needs Feedback to Closed
- % Done changed from 0 to 100
Riccardo De Contardi wrote:
config.stat_mysql and config.stat_apache have been removed in TYPO3 6.0
Not only these, but all config.stat* options have been removed.
Updated by Felix Nagel almost 11 years ago
So this is still a bug in 4.x which will be supported at least till April 2014. Why do you close this ticket?
Three years without any feedback from the core team and now you close a valid bug report? Very nice.
Updated by Chris topher almost 11 years ago
- Status changed from Closed to Needs Feedback
- % Done changed from 100 to 0
Felix Nagel wrote:
So this is still a bug in 4.x which will be supported at least till April 2014. Why do you close this ticket?
Three years without any feedback from the core team and now you close a valid bug report? Very nice.
Ok, opened again...
However, I do not expect any crucial activity to happen here. No one has fixed this bug for years and that when the functionality was present. I do not expect anyone to now suddenly fix it; additionally since this functionality has - in newer versions - been abandoned.
Updated by Felix Nagel almost 11 years ago
I do not expect much to happen here too, but closing valid bug reports just because you think its irrelevant is the best way to make sure people wont post issues at all.
Updated by Chris topher almost 11 years ago
We'll see, if someone really wants to waste his time on an already removed feature.
Updated by Alexander Opitz almost 11 years ago
- Status changed from Needs Feedback to New
Updated by Christian Kuhn over 9 years ago
- Status changed from New to Rejected
- Is Regression set to No
Hey.
I'm sorry, but this issue will definitely not be fixed in 4.5 anymore, since this version is in security only bugfix mode already, so even if someone wanted to work on it, it would not be merged to 4.5 core anymore.
The whole functionality was removed with 6.0 already, so 6.2 does not have this bug.
There is no point in having issues open that will not be fixed for sure, therefor i will close this issue as "rejected" to not disturb the overview of issues that do have a chance of being fixed. I'm sure you understand this.