TYPO3-Core throws PHP-Warnings (function "parse_url()") if $_SERVER['HTTP_HOST'] is empty
|Priority:||Should have||Due date:|
|Assigned To:||-||% Done:||
|TYPO3 Version:||4.3||Is Regression:||No|
|PHP Version:||5.2||Sprint Focus:|
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)
#1 Updated by Steffen Gebert over 4 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?
#2 Updated by Andy Grunwald over 4 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?
#3 Updated by Steffen Gebert over 4 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..)
#4 Updated by Andy Grunwald over 4 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
#5 Updated by Alexander Opitz over 1 year ago
- Category deleted (
- Status changed from New to Needs Feedback
- Target version deleted (
- Is Regression set to No
as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (6.1.7)?
#6 Updated by Alexander Opitz about 1 year ago
- Status changed from Needs Feedback to Closed
No feedback within the last 90 days => closing this ticket.
If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.