[TYPO3-core] RFC: Bug #5985 - warning when CURLOPT_FOLLOWLOCATION is set

Martin Kutschker Martin.Kutschker at n0spam-blackbox.net
Tue Aug 7 09:23:25 CEST 2007


Ernesto Baschny [cron IT] schrieb:
> Martin Kutschker wrote: on 06.08.2007 21:48:
> 
>> Branches: trunk, TYPO3_4-1
>>
>> Problem: Since PHP 5.2.0, 5.1.5 and 4.4.4 (see PHP Changelog)
>> CURLOPT_FOLLOWLOCATION is not allowed when open_basedir or safe_mode are
>> enabled. curl_setopt() will issue a warning in this case.
>>
>> Solution: suppress output with @.
> 
> +1 on that and also backporting to 4.0, if you have the time to do that
> and Stucki agrees. Because I see that a lot of web hoster will be
> upgrading their PHP versions and older installations will simply start
> giving out this warning.
> 
>> Optional: check the return value of curl_setopt() and log a failure.
> 
> I would output a warning only IF getUrl fails because of not following a
> "Location:" header, otherwise we don't need to worry the admin / hoster.
> The majority of cases probably don't require to follow a Location in the
> first place.
> 
> Is this something we can recognize? If CURLOPT_FOLLOWLOCATION is OFF
> (curl_setopt returned false) and we hit a "Location:" header, what will
> curl_exec() return? Maybe we should always switch "CURLOPT_HTTPHEADER"
> on and check for that there and then give out a warning instead and then
> later strip off the header if the $includeHeader was not wanted.

But getURL doesn't report any errors right now. It's extremely dumb and the 
user/admin cannot tell why getURL failed. So why make an excepmtion here?

My suggestion: apply the patch as-is to 4.0 and 4.1 and create a better 
getURL for 4.2. My plan (posted on this list) was to write to turn getURL 
into a wrapper to a function with proper error reporting. Not logging, but 
returning a meaningful error string for the application.

Masi


More information about the TYPO3-team-core mailing list