Project

General

Profile

Actions

Bug #17570

closed

pageNotFound_handling outputs a blank page if the given URL could no be retreived via CURL or fopen

Added by Helmut Hummel about 17 years ago. Updated over 16 years ago.

Status:
Closed
Priority:
Should have
Category:
Communication
Target version:
-
Start date:
2007-08-30
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.1
PHP Version:
4.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

If allow_url_fopen is set to 'no' and curl is not set up correctly, and $TYPO3_CONF_VARS['FE']['pageNotFound_handling'] is set to an URL, then simply a blank page is set to the user which is quite confusing.

(issue imported from #M6240)


Files

bug_6240.diff (732 Bytes) bug_6240.diff Administrator Admin, 2007-08-30 13:35
bug_6240_v2.diff (728 Bytes) bug_6240_v2.diff Administrator Admin, 2007-09-02 11:12
Actions #1

Updated by Helmut Hummel about 17 years ago

Added Patch, which fixes the check when no content is returned by t3lib_div::getURL and an error message is shown, with hints what can be checked. I removed the redirection with header(location: ..) because redirection can be done by setting pagenotfound_handling to 'REDIRECT:<url>'

Actions #2

Updated by Martin Kutschker about 17 years ago

You changed the check from FALSE to "\r\n". Isn't CURL supposed to return a boolean FALSE on error?

As for the action, too me it makes more sense to fall back to the standard TYPO3 error page and write the failure to the log (t3lib_div::sysLog)

Actions #3

Updated by Helmut Hummel about 17 years ago

You're right in that point, that t3lib_div::getURL returns false if an error occured fetching data from the URL (nothing to do with CURL, as this function decides whether to use CURL or not). But then the check must at least be changed to

if ($res === false)

because $res contains the return value of the function and $content is at least filled with "\r\n" directly before the if

$content.= "\r\n";

so $content will never be boolean!

For the error page:
I don't know what you mean, as my patch will change the behaviour from silently using a redirect, to showing the standard TYPO3 error page using the function $this->printError as it is done in the whole class tslib_fe.

Of course logging the failure would be nice, but then should be done by extending printError function.

Actions #4

Updated by Helmut Hummel about 17 years ago

Add revised patch

Actions #5

Updated by Ernesto Baschny almost 17 years ago

Commited to:

- trunk (rev. 2756) (for 4.2-alpha3)
- TYPO3_4-1 (rev. 2757) (for 4.1.4)

Actions

Also available in: Atom PDF