TYPO3-Core throws PHP-Warnings (function "parse_url()") if $_SERVER['HTTP_HOST'] is empty
|Status:||Needs Feedback||Start date:||2011-01-10|
|Priority:||Should have||Due date:|
|PHP Version:||5.2||Is Regression:||No|
If the Variable $_SERVER['HTTP_HOST'] is empty / not set, the TYPO3 Core throws PHP Warnings. This variable is empty if a HTTP request is done with HTTP/1.0 (HTTP version 1.0). This version of HTTP don`t support HTTP_HOST.
With a request with HTTP/1.0, TYPO3 acts to show the "Page not Found"-Website.If you configure [FE][pageNotFound_handling] (Install-Tool) with the value "/404/" (Show the page http://www.domain.com/404/ if a page wasn`t found) the following PHP warning appear:
Core: Error handler (FE): PHP Warning: parse_url(http:///404/) [<a href='function.parse-url'>function.parse-url</a>]: Unable to parse URL in /var/www/bitburger-braugruppe.de/typo3_src-4.3.10/t3lib/class.t3lib_div.php line 3315
If you switch the [FE][pageNotFound_handling]-value to "http://www.domain.com/404/" the following php warning will appear:
Core: Error handler (FE): PHP Warning: parse_url(http:///) [<a href='function.parse-url'>function.parse-url</a>]: Unable to parse URL in /var/www/bitburger-braugruppe.de/typo3_src-4.3.10/t3lib/class.t3lib_userauth.php line 1170
IMPORTANT: The request must use HTTP in version 1.0!
A work-a-round is to use "REDIRECT:http://www.domain.com/404/" as [FE][pageNotFound_handling]-value, but in my opinion this is not a real solution.
Webserver: Apache 2
Following lines are affected:
in tslib_fe::pageErrorHandler the incomming url ($code) is modified in line 1500:
$code = t3lib_div::getIndpEnv('TYPO3_REQUEST_HOST') . $code;
The call t3lib_div::getIndpEnv('TYPO3_REQUEST_HOST') relies on t3lib_div::getIndpEnv('HTTP_HOST'). t3lib_div::getIndpEnv('TYPO3_REQUEST_HOST') doesn`t check if the return value of t3lib_div::getIndpEnv('HTTP_HOST') is empty.
And so urls like http:///404/ (with [FE][pageNotFound_handling] = "/404/") or http:/// (with [FE][pageNotFound_handling] = "http://www.domain.com/404/") are created
What the hell? How do you find such a bug? Which one is using HTTP 1.0 ???
The networking monitoring tool "Whats Up" from "Ipswitch" (http://www.whatsupgold.com/) make http requests to check the uptime. This tool uses in some cases HTTP in version 1.0
(issue imported from #M16960)
Updated by Steffen Gebert over 3 years ago
Thanks for the report, Andy!
Isn't it that Host is optional for HTTP/1.0, but required for 1.1?
Nevertheless, 1.0 isn't also that unlikely, several proxies only talk 1.0
Could you create a patch?
Updated by Andy Grunwald about 3 years ago
thanks for your fast reply.
In my opinion there are two challanges in this issue:
1. We must find a way to send a HTTP/1.0 request manually to reproduce this problem. Actually i don`t know a way how to make a HTPP/1.0 request (but i`ven`t searched for it, now).
2. What is the right solution for it? How must TYPO3 react?
To wrap all parse_url()-Calls which are affected? To determine the HTTP_HOST in an alternative way, if it a HTTP/1.0 request? Or if it empty?
What is your thought about it?
Updated by Steffen Gebert about 3 years ago
Sorry, I haven't really thought about it. That's why I asked you, as it seems like you've already digged into it.
I would say, the places where parse_url() uses HTTP_HOST should get a check, whether HTTP_HOST is empty. What the remedy shoud be - don't know. In case of the pageNotFound_handling redirect, we might redirect to /404.html, however that's not RFC-conform.
Submitting an HTTP/1.0 request is pretty easy
$ telnet localhost 80 GET / HTTP/1.0
You have to press Enter twice after the GET line (as empty line denotes the end of header section).
If you want to submit a host name, just add the line
It might be also possible in firefox:
open about:config and change network.http.version to 1.0.
Using TamperData, you can remove the Host value (however untested..)
Updated by Andy Grunwald about 3 years ago
I had a talk with Steffen for a few minutes.
We talked about this problem and he offered his help.
If i had some time i will digg into it and think about a right solution. But you know it: A monster is eating our time!
In additon: An interessting link - >http://shiflett.org/blog/2006/mar/server-name-versus-http-host