Project

General

Profile

Actions
Copy link

Bug #73702

closed

mirrors.xml.gz file includes HTTP headers, curl settings bug?

Added by Paul Buechler over 8 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2016-02-26
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
7
PHP Version:
5.5
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

Hello there,

I have the problem that the TER update fails. We figured out that the mirrors.xml.gz file is the problem and that it includes a HTTP Header which looks like this:

<snip>
   HTTP/1.1 200 OK
   Date: Thu, 25 Feb 2016 09:25:51 GMT
   Server: Apache
   Last-Modified: Mon, 25 Jan 2016 19:40:36 GMT
   ETag: "fa5de6-109-52a2dbe316ea2" 
   Accept-Ranges: bytes
   Content-Length: 265
   Vary: Accept-Encoding
   Connection: close
   Content-Type: application/x-gzip
   BINARY DATA...
   </snip>

After a lot of testing we could solve the problem by editting this file: typo3_src-7.6.4/typo3/sysext/core/Classes/Utility/GeneralUtility.php.
So we changed the following line, that it won't include the header:

//      curl_setopt($ch, CURLOPT_HEADER, !$followLocationSucceeded || $includeHeader ? 1 : 0);
            curl_setopt($ch, CURLOPT_HEADER, 0);

Is this a known problem and is there a better solution than manually editing files?

Best regards,
Paul

These are our system information:

OS: Ubuntu 14.04.4 LTS
Webserver: Apache/2.4.7
PHP: 5.5.9-1ubuntu4.14
PHP-CURL: 5.5.9+dfsg-1ubuntu4.14
Proxy: Squid 3.1.19-1ubuntu3.12.04.4
Typo3: 7.6.4

settings php.ini:

disable_functions =     pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,
                        pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,
                        pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,
                        pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,
                        pcntl_exec,pcntl_getpriority,pcntl_setpriority
open_basedir =  "/var/www:/tmp:/usr/share/lib/php:/usr/share/php:/usr/share/phpmyadmin:
                        /usr/share/pear:/var/lib/php5:/var/run/php5:/etc/php5:/etc/pear:
                        /usr/bin/pear:/usr/bin/peardev:/var/lib/phpmyadmin:/etc/phpmyadmin"

settings LocalConfiguration.php:

'HTTP' => [
        'adapter' => 'curl',
        'proxy_host' => '1.2.3.4',
        'proxy_port' => '3128',
      ],
        'curlProxyServer' => 'http://1.2.3.4:3128/',
        'curlUse' => '1',
Actions
Copy link
 #1

Updated by Markus Klein over 8 years ago

Can you tell us what values the variables $followLocationSucceeded and $includeHeader have?

Actions
Copy link
 #2

Updated by Markus Klein over 8 years ago

Usually $includeHeader should be 0 for this call, so I suspect that this call fails at your server:

$followLocationSucceeded = @curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);

Hence, $followLocationSucceeded is false and the headers are being fetched.

Read also http://php.net/manual/en/function.curl-setopt.php#113682

Actions
Copy link
 #3

Updated by Paul Buechler over 8 years ago

I don't know if this is a bug. open_basedir is set like I wrote in the bugreport. Maybe it changes variables, so they won't work right.

Markus Klein wrote:

Read also http://php.net/manual/en/function.curl-setopt.php#113682

The page said:

"... then you will want to read http://www.php.net/ChangeLog-4.php which says "Disabled CURLOPT_FOLLOWLOCATION in curl when open_basedir or safe_mode are enabled." as of PHP 4.4.4/5.1.5. ..."

Actions
Copy link
 #4

Updated by Markus Klein over 8 years ago

I can see no mistake in the code and the code is there for a very long time. Also I can't test/reproduce the issue, so I can only suggest:
Maybe just disable curl on your setup (Install Tool), then the issue should be gone.

Actions
Copy link
 #5

Updated by Paul Buechler over 8 years ago

could you test it behind a proxy? If we disable curl it won't work either.

Actions
Copy link
 #6

Updated by Markus Klein over 8 years ago

  • Status changed from New to Closed

If you disable curl, then the Core will simply use the PHP function 'file_get_contents'. So anything that does not work now, is fully up to your PHP configuration. I have absolutely no experience with proxies in that regard.

Since this is very unlikely a Core bug and this is a bug tracker only, I'll close this ticket now.
Please use Slack or the mailing lists for more help from a broader community.
(https://forger.typo3.org/slack)

Thanks.

Actions
Copy link

Also available in: Atom PDF