Core: Error: server is not connected to the internet message - but I am, or so I think ...

Created on 11 May 2015  Â·  89Comments  Â·  Source: owncloud/core

Steps to reproduce

  1. Install 8.1
  2. Navigate to the admin page
  3. Check the security warnings

    Expected behaviour

They should make sense

Actual behaviour

This one doesn't make sense as I am connected to the internet:

p340

More information is needed (a pointer to a link?) on how to resolve this.

Server Host info:

Ubuntu 14.04
PHP 5.5.9

Server configuration:

ownCloud Enterprise Edition 8.1 beta 1 (daily) Build:2015-05-11T03:08:42+00:00 52fc45e6e3d271c94d801af377c85974e1420d2e

Bug needs info sev3-medium

Most helpful comment

To fix the problem on Ubuntu 13.04 or 14.04, you can actually follow these instructions

  • Use this custom PPA to update your cURL
  • Fetch the latest ca-bundle.crt by executing wget https://raw.githubusercontent.com/owncloud/core/stable8.1/config/ca-bundle.crt in your config folder.

This made things work for me again.
Additionally anyone upgrading should check for empty or invalid proxy settings in their config.php

All 89 comments

i can confirm this, how is the connection checked ? maybe something is missing ...

@LukasReschke

Please create a test.php in the same directory as your index.php with the following input and report the output:

<?php

require_once('./lib/base.php');


$client = \OC::$server->getHTTPClientService()->newClient();
try {
    $client->get('https://www.owncloud.org/');
    $client->get('http://www.owncloud.org/');
} catch (\Exception $e) {
    throw $e;
}

Also be sure to add define('DEBUG', true); at top of your config.php so that we have a proper stacktrace.

Thanks for your Help, here is the trace:

_Interner Serverfehler_

Der Server hat einen internen Fehler und konnte Ihre Anfrage nicht
vervollständigen.

Bitte wende Dich an den Serveradministrator, sollte dieser Fehler mehrfach
auftreten, und fĂĽge Deiner Anfrage die unten stehenden technischen Details
bei.

Weitere Details können im Serverprotokoll gefunden werden.

_Technische Details_

Entfernte Adresse: 2a02:2450:102d:3ff:cd66:9893:147a:7cAnforderungskennung:
VVJssn8AAAEAAGcnRB8AAAAGTyp: GuzzleHttp\Exception\RequestExceptionCode:
0Nachricht: cURL error 5: Could not resolve proxy:
www.aaaaowncloud.orgDatei:
/var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/Exception/RequestException.phpZeile:
51

_Spur_

0 /var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php(104):

GuzzleHttp\Exception\RequestException::wrapException(Object(GuzzleHttp\Message\Request),
Object(GuzzleHttp\Ring\Exception\RingException)) #1
/var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php(132):
GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction)) #2
/var/www/owncloud/3rdparty/react/promise/src/FulfilledPromise.php(24):
GuzzleHttp\RequestFsm->GuzzleHttp{closure}(Array) #3
/var/www/owncloud/3rdparty/guzzlehttp/ringphp/src/Future/CompletedFutureValue.php(55):
React\Promise\FulfilledPromise->then(Object(Closure), NULL, NULL) #4
/var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/Message/FutureResponse.php(43):
GuzzleHttp\Ring\Future\CompletedFutureValue->then(Object(Closure), NULL,
NULL) #5
/var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php(135):
GuzzleHttp\Message\FutureResponse::proxy(Object(GuzzleHttp\Ring\Future\CompletedFutureArray),
Object(Closure)) #6
/var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/Client.php(232):
GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction)) #7
/var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/Client.php(192):
GuzzleHttp\Client->send(Object(GuzzleHttp\Message\Request)) #8
/var/www/owncloud/lib/private/http/client/client.php(122):
GuzzleHttp\Client->get('https://www.aaa...', Array) #9
/var/www/owncloud/test.php(3): OC\Http\Client\Client->get('https://www.aaa...')

10 {main}

Am 12.05.2015 09:46 schrieb "Lukas Reschke" [email protected]:

Please create a test.php in the same directory as your index.php with the
following input and report the output:

getHTTPClientService()->newClient();try { $client->get('https://www.aaaaowncloud.org/'); $client->get('http://www.owncloud.org/');} catch (\Exception $e) { throw $e;}

Also be sure to add define('DEBUG', true); at top of your config.php so
that we have a proper stacktrace.

—
Reply to this email directly or view it on GitHub
https://github.com/owncloud/core/issues/16255#issuecomment-101173236.

and once more without that AAA in the URL:
Interner Serverfehler
Der Server hat einen internen Fehler und konnte Ihre Anfrage nicht vervollständigen.
Bitte wende Dich an den Serveradministrator, sollte dieser Fehler mehrfach auftreten, und fĂĽge Deiner Anfrage die unten stehenden technischen Details bei.
Weitere Details können im Serverprotokoll gefunden werden.

Technische Details
Entfernte Adresse: 2a02:2450:102d:3ff:cd66:9893:147a:7c
Anforderungskennung: VVJuXn8AAAEAAGlEY7kAAAAC
Typ: GuzzleHttp\Exception\RequestException
Code: 0
Nachricht: cURL error 56: Proxy CONNECT aborted
Datei: /var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/Exception/RequestException.php
Zeile: 51

Spur

0 /var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php(104): GuzzleHttp\Exception\RequestException::wrapException(Object(GuzzleHttp\Message\Request), Object(GuzzleHttp\Ring\Exception\RingException))

1 /var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php(132): GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))

2 /var/www/owncloud/3rdparty/react/promise/src/FulfilledPromise.php(24): GuzzleHttp\RequestFsm->GuzzleHttp{closure}(Array)

3 /var/www/owncloud/3rdparty/guzzlehttp/ringphp/src/Future/CompletedFutureValue.php(55): React\Promise\FulfilledPromise->then(Object(Closure), NULL, NULL)

4 /var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/Message/FutureResponse.php(43): GuzzleHttp\Ring\Future\CompletedFutureValue->then(Object(Closure), NULL, NULL)

5 /var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php(135): GuzzleHttp\Message\FutureResponse::proxy(Object(GuzzleHttp\Ring\Future\CompletedFutureArray), Object(Closure))

6 /var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/Client.php(232): GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))

7 /var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/Client.php(192): GuzzleHttp\Client->send(Object(GuzzleHttp\Message\Request))

8 /var/www/owncloud/lib/private/http/client/client.php(122): GuzzleHttp\Client->get('https://www.own...', Array)

9 /var/www/owncloud/test.php(3): OC\Http\Client\Client->get('https://www.own...')

10 {main}

@derkostka Interesting. Can you post your config.php and also try by fixing the aaaaaowncloud.org to owncloud.org - technically it should fail then as well if it is what I suspect. Thanks!

Ah you were faster ;-) - Config.php still applies :-)

Sure !

Please consider that if i upgrade i usually keep the old config. May be
something is missing here for OC 8.1 ...

Welcome to Ubuntu 15.04 (GNU/Linux 3.8.13.28 armv7l)

cat /var/www/owncloud/config/config.php
define('DEBUG', true);
$CONFIG = array (
'instanceid' => 'someocinstanceid',
'passwordsalt' => 'tastysalt',
'hashingCost' => 10,
'trusted_domains' =>
array (
0 => 'cloud.sebastiankostka.de',
1 => 'de1.portmap64.net',
2 => '192.168.6.9',
3 => 'odroid',
4 => 'vpn',
),
'datadirectory' => '/media/data/owncloud/data',
'version' => '8.1.0.5',
'dbtype' => 'mysql',
'dbhost' => '127.0.0.1',
'dbname' => 'owncloud',
'dbuser' => 'ownclouduser',
'dbpassword' => 'mysecretpassword',
'dbtableprefix' => 'oc_',
'sqlite.journal_mode' => 'DELETE',
'installed' => true,
'default_language' => 'de',
'defaultapp' => 'files',
'knowledgebaseenabled' => true,
'enable_avatars' => true,
'allow_user_to_change_display_name' => true,
'remember_login_cookie_lifetime' => 1296000,
'session_lifetime' => 86400,
'session_keepalive' => true,
'skeletondirectory' => '',
'mail_domain' => 'mydomain',
'mail_from_address' => 'owncloud',
'mail_smtpdebug' => false,
'mail_smtpmode' => 'smtp',
'mail_smtphost' => 'mail',
'mail_smtpport' => 465,
'mail_smtptimeout' => 10,
'mail_smtpsecure' => 'ssl',
'mail_smtpauth' => true,
'mail_smtpauthtype' => 'LOGIN',
'mail_smtpname' => 'me@mymail',
'mail_smtppassword' => 'secret',
'overwritehost' => '',
'overwriteprotocol' => '',
'overwritewebroot' => '',
'overwritecondaddr' => '',
'overwrite.cli.url' => '',
'proxy' => '',
'proxyuserpwd' => '',
'trashbin_retention_obligation' => 30,
'trashbin_auto_expire' => true,
'appcodechecker' => false,
'updatechecker' => true,
'has_internet_connection' => true,
'check_for_working_webdav' => true,
'check_for_working_htaccess' => true,
'config_is_read_only' => false,
'log_type' => 'owncloud',
'logfile' => '/var/log/owncloud.log',
'loglevel' => 0,
'logdateformat' => 'F d, Y H:i:s',
'logtimezone' => 'Europe/Berlin',
'log_query' => false,
'cron_log' => true,
'log_rotate_size' => 104857600,
'3rdpartyroot' => '',
'3rdpartyurl' => '',
'customclient_desktop' => 'http://owncloud.org/sync-clients/',
'customclient_android' => '
https://play.google.com/store/apps/details?id=com.owncloud.android',
'customclient_ios' => '
https://itunes.apple.com/us/app/owncloud/id543672169?mt=8',
'appstoreenabled' => true,
'appstoreurl' => 'https://api.owncloud.com/v1',
'apps_paths' =>
array (
0 =>
array (
'path' => '/var/www/owncloud/apps',
'url' => '/apps',
'writable' => true,
),
1 =>
array (
'path' => '/var/www/owncloud/apps2',
'url' => '/apps2',
'writable' => true,
),
),
'enable_previews' => true,
'preview_max_x' => NULL,
'preview_max_y' => NULL,
'preview_max_scale_factor' => 10,
'preview_max_filesize_image' => 50,
'preview_libreoffice_path' => '/usr/bin/libreoffice',
'preview_office_cl_parameters' => ' --headless --nologo
--nofirststartwizard --invisible --norestore -convert-to pdf -outdir ',
'enabledPreviewProviders' =>
array (
0 => 'OC\Preview\Image',
1 => 'OC\Preview\MP3',
2 => 'OC\Preview\TXT',
3 => 'OC\Preview\MarkDown',
),
'ldapUserCleanupInterval' => 51,
'maintenance' => false,
'singleuser' => false,
'forcessl' => true,
'forceSSLforSubdomains' => true,
'openssl' =>
array (
'config' => '/absolute/location/of/openssl.cnf',
),
'blacklisted_files' =>
array (
0 => '.htaccess',
),
'share_folder' => '/',
'theme' => '',
'xframe_restriction' => true,
'cipher' => 'AES-256-CFB',
'redis' =>
array (
'host' => 'localhost',
'port' => 6379,
'timeout' => 0,
),
'memcached_servers' =>
array (
0 =>
array (
0 => 'localhost',
1 => 11211,
),
),
'cache_path' => '',
'quota_include_external_storage' => false,
'filesystem_check_changes' => 1,
'asset-pipeline.enabled' => false,
'assetdirectory' => '/var/www/owncloud',
'mount_file' => 'data/mount.json',
'filesystem_cache_readonly' => false,
'supportedDatabases' =>
array (
0 => 'sqlite',
1 => 'mysql',
2 => 'pgsql',
3 => 'oci',
4 => 'mssql',
),
'custom_csp_policy' => 'default-src \'self\'; script-src \'self\'
\'unsafe-eval\'; style-src \'self\' \'unsafe-inline\'; frame-src *; img-src
*; font-src \'self\' data:; media-src *; connect-src *',
'secret' => 'somesecret',
'trusted_proxies' =>
array (
0 => '203.0.113.45',
1 => '198.51.100.128',
),
'forwarded_for_headers' =>
array (
0 => 'HTTP_X_FORWARDED',
1 => 'HTTP_FORWARDED_FOR',
),
'max_filesize_animated_gifs_public_sharing' => 10,
'ldapIgnoreNamingRules' => false,
);
Am 12.05.2015 23:21 schrieb "Lukas Reschke" [email protected]:

@derkostka https://github.com/derkostka Interesting. Can you post your
config.php and also try by fixing the aaaaaowncloud.org to owncloud.org -
technically it should fail then as well if it is what I suspect. Thanks!

—
Reply to this email directly or view it on GitHub
https://github.com/owncloud/core/issues/16255#issuecomment-101425597.

@derkostka
Seems you have copied over the config.sample.php? :see_no_evil:

@RealRancor
edit: had to read twice, it's late .. sorry.

anyway, if it is a configuration problem the error message should indicate that.

so yes, I copied over the sample and did my modifications as far as I knew them ...

@derkostka
In general copying over the config.sample.php is not supported and can cause various issues. Newer versions of OC will also "bail out" if you're doing this there:

https://github.com/owncloud/core/blob/v8.0.3/config/config.sample.php#L7-L10
https://github.com/owncloud/core/blob/v8.0.3/config/config.sample.php#L973-L980

The second message you have posted says:

"cURL error 56: Proxy CONNECT aborted"

Your current config.php contains the default "trusted_proxies" setting:

https://github.com/owncloud/core/blob/v8.0.3/config/config.sample.php#L955

which could cause this.

Thanks for the pointer. Good to see this one is probably (my) configuration fault. @jnfrmarks does this also apply to you ?

Edit: I did remove all Proxy-relations i´ve seen from the config, still:
Nachricht: cURL error 56: Proxy CONNECT aborted

I am away for the weekend, but i will rework my complete config and look again in a test instance. meanwhile, let´s wait for jnfrmarks reply. Thanks for the support !

@RealRancor @derkostka @LukasReschke

I'm getting back to this now and don't know what I need to do here. I still see the warning on my CentOS system but not on my ubuntu system.

@jnfrmarks Any way you can grant me access to that system?

Relevant error entry:

{"reqId":"gYucJ95zFT8VH1f3+Htt","remoteAddr":"172.16.12.96","app":"PHP","message":"GuzzleHttp\\Exception\\ClientException: Client error response [url] https:\/\/owncloud.org\/ [status code] 400 [reason phrase] Bad Request at \/var\/www\/html\/owncloud\/3rdparty\/guzzlehttp\/guzzle\/src\/Exception\/RequestException.php#89","level":3,"time":"2015-06-16T07:23:58+00:00","method":"GET","url":"\/owncloud\/test.php"}

When dumping the error entry:


object(GuzzleHttp\Message\Response)#486 (7) {
  ["reasonPhrase":"GuzzleHttp\Message\Response":private]=>
  string(11) "Bad Request"
  ["statusCode":"GuzzleHttp\Message\Response":private]=>
  int(400)
  ["effectiveUrl":"GuzzleHttp\Message\Response":private]=>
  string(29) "https://owncloud.org/test.php"
  ["headers":"GuzzleHttp\Message\AbstractMessage":private]=>
  array(8) {
    ["date"]=>
    array(1) {
      [0]=>
      string(29) "Tue, 16 Jun 2015 15:24:52 GMT"
    }
    ["server"]=>
    array(1) {
      [0]=>
      string(6) "Apache"
    }
    ["x-frame-options"]=>
    array(1) {
      [0]=>
      string(10) "SAMEORIGIN"
    }
    ["strict-transport-security"]=>
    array(1) {
      [0]=>
      string(16) "max-age=31536000"
    }
    ["x-xss-protection"]=>
    array(1) {
      [0]=>
      string(13) "1; mode=block"
    }
    ["content-length"]=>
    array(1) {
      [0]=>
      string(3) "347"
    }
    ["connection"]=>
    array(1) {
      [0]=>
      string(5) "close"
    }
    ["content-type"]=>
    array(1) {
      [0]=>
      string(29) "text/html; charset=iso-8859-1"
    }
  }
  ["headerNames":"GuzzleHttp\Message\AbstractMessage":private]=>
  array(8) {
    ["date"]=>
    string(4) "Date"
    ["server"]=>
    string(6) "Server"
    ["x-frame-options"]=>
    string(15) "X-Frame-Options"
    ["strict-transport-security"]=>
    string(25) "Strict-Transport-Security"
    ["x-xss-protection"]=>
    string(16) "X-XSS-Protection"
    ["content-length"]=>
    string(14) "Content-Length"
    ["connection"]=>
    string(10) "Connection"
    ["content-type"]=>
    string(12) "Content-Type"
  }
  ["body":"GuzzleHttp\Message\AbstractMessage":private]=>
  object(GuzzleHttp\Stream\Stream)#487 (7) {
    ["stream":"GuzzleHttp\Stream\Stream":private]=>
    resource(421) of type (stream)
    ["size":"GuzzleHttp\Stream\Stream":private]=>
    NULL
    ["seekable":"GuzzleHttp\Stream\Stream":private]=>
    bool(true)
    ["readable":"GuzzleHttp\Stream\Stream":private]=>
    bool(true)
    ["writable":"GuzzleHttp\Stream\Stream":private]=>
    bool(true)
    ["uri":"GuzzleHttp\Stream\Stream":private]=>
    string(10) "php://temp"
    ["customMetadata":"GuzzleHttp\Stream\Stream":private]=>
    array(0) {
    }
  }
  ["protocolVersion":"GuzzleHttp\Message\AbstractMessage":private]=>
  string(3) "1.1"
}

This means 172.18.5.39 gets a 400 returned from owncloud.org which results in this behaviour since a 400 status code is an error. Requires investigation on the owncloud.org server side as well. (on it)

On the owncloud.org server:

[Tue Jun 16 17:28:24 2015] [error] [client XXXX] Re-negotiation request failed
[Tue Jun 16 17:28:24 2015] [error] SSL Library Error: 336068946 error:14080152:SSL routines:SSL3_ACCEPT:unsafe legacy renegotiation disabled
[Tue Jun 16 17:28:24 2015] [error] [client XXXX] Re-negotiation request failed
[Tue Jun 16 17:28:24 2015] [error] SSL Library Error: 336068946 error:14080152:SSL routines:SSL3_ACCEPT:unsafe legacy renegotiation disabled
[Tue Jun 16 17:28:30 2015] [error] Hostname www.owncloud.org provided via SNI and hostname owncloud.org provided via HTTP are different
[Tue Jun 16 17:28:30 2015] [error] Hostname www.owncloud.org provided via SNI and hostname owncloud.org provided via HTTP are different

Looks like an SNI related issue. Digging…

Looks like an SNI related issue

Thought about the same. Is curl used for this request?

Is curl used for this request?

Yup. With 8.1 we always use the PHP cURL bindings in form of a wrapper around GuzzleHttp.

This is a PHP bug: https://bugs.php.net/bug.php?id=67639

For testing purposes:

<?php
function doCurl($url) {
    $ch = curl_init($url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    $result = curl_exec($ch);
    $code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);
    return $code;
}
echo "HTTP Status: ".doCurl("https://owncloud.org")."\n";
echo "HTTP Status: ".doCurl("https://www.owncloud.org")."\n";

If the second line returns a 400 then the PHP version is affected by this bug.

@LukasReschke

Is there something we need to do to either remove the bug message or let the customer know about the php bug?

Well… Recompiling PHP with a newer cURL version might help. Besides that everything else that we can do is only cosmetic and it is indeed possibly that this breaks other features as well when it comes to handling connections to hosts with SNI. Though having connections in the same PHP request to two different domains running on the same server with SNI is unlikely. I would however not say that this is impossible.

If we just want to get rid of this error we need to stop using SNI on owncloud.org, for this please get in touch with sysadmin.

On the first moment I can think about S2S breaking when handling SNI stuff with an alias, for example when the ownCloud instance is accessible from www.owncloud.org as well as owncloud.org, in this case the file cache and whatever might go :boom:

So, seems like this conversation may have taken a break. Looked over the php bug, no activity there. So, I just modified settings/controller/checksetupcontroller.php and took the www's out of the urls and that fixed it. Pretty simple and seems like the right thing to do since www.owncloud.org just redirects to owncloud.org anyway.

This fixes just the symptom. Not the bug. There will be other places in ownCloud where stuff will explode. I'd prefer to show a warning then instead of showing "all fine" when in fact it isn't.

The PHP Bug has been discovered on 5.5

I still see the message in OC8.1-RC1, backed by php 5.6.

I will double check this evening.

I didn't say it was a fix for the bug, all I wanted was 1) an understanding of why the error was showing up and 2) a way to make it go away.

If the warning is valid then yes, show it. However the warning presented says nothing to what the problem really is. In fact it is just confusing. "No internet access" when I clearly do have internet access is a bogus error and thus useless. While true that the error did point out that a problem exists, we now know what the problem is and can fix it. But to unsuspecting John Doe, that error points him in the wrong direction.

Maybe a new error is needed that throws a useful exception when the (unlikely) problem does manifest, if the actual problem can't be fixed in owncloud (since the bug is in php itself).

By the way, I upgraded to PHP 5.6.10 and the problem is still present. (ownCloud 8.1 RC1 (testing))

Well… Recompiling PHP with a newer cURL version might help.

Please post your cURL version and run the test script from https://github.com/owncloud/core/issues/16255#issuecomment-112481294

cURL Information 7.29.0

Results from test.php:
HTTP Status: 200 HTTP Status: 400

curl 7.38.0 (arm-unknown-linux-gnueabihf)
PHP 5.6.4-4ubuntu6 (cli)

test.php:
HTTP Status: 200
HTTP Status: 301

--> which is the expected result, afaik this php version should be fine ? i still see the message, double-checked my config also (at least i removed the proxy-default setting)

Same error using CentOS 7.1
php: php-5.4.16-36.el7_1.x86_64
libcurl: libcurl-7.29.0-19.el7.x86_64

Test result:
HTTP Status: 200 HTTP Status: 400

I have the same problem.
test.php:
HTTP Status: 200
HTTP Status: 301

System: Debian stable
Apache 2.4.10-10
PHP5: 5.6.9+dfsg-0+deb8u1
libcurl: 7.38.0-4+deb8u2

Edit:
ownCloud 8.1.0 (stable)

I have the same problem.

Using the test.php I get this:

Internal Server Error
The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.

Technical details
Remote Address: 192.168.1.1
Request ID: VZwGPehLYWjb7wGAFGdAuwAAAAI
Type: GuzzleHttp\Exception\ClientException
Code: 400
Message: Client error response [url] https://owncloud.org/ [status code] 400 [reason phrase] Bad Request
File: /var/www/html/owncloud/3rdparty/guzzlehttp/guzzle/src/Exception/RequestException.php
Line: 89

Trace

0 /var/www/html/owncloud/3rdparty/guzzlehttp/guzzle/src/Subscriber/HttpError.php(33): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Message\Request), Object(GuzzleHttp\Message\Response))

1 /var/www/html/owncloud/3rdparty/guzzlehttp/guzzle/src/Event/Emitter.php(109): GuzzleHttp\Subscriber\HttpError->onComplete(Object(GuzzleHttp\Event\CompleteEvent), 'complete')

2 /var/www/html/owncloud/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php(91): GuzzleHttp\Event\Emitter->emit('complete', Object(GuzzleHttp\Event\CompleteEvent))

3 /var/www/html/owncloud/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php(132): GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))

4 /var/www/html/owncloud/3rdparty/react/promise/src/FulfilledPromise.php(24): GuzzleHttp\RequestFsm->GuzzleHttp{closure}(Array)

5 /var/www/html/owncloud/3rdparty/guzzlehttp/ringphp/src/Future/CompletedFutureValue.php(55): React\Promise\FulfilledPromise->then(Object(Closure), NULL, NULL)

6 /var/www/html/owncloud/3rdparty/guzzlehttp/guzzle/src/Message/FutureResponse.php(43): GuzzleHttp\Ring\Future\CompletedFutureValue->then(Object(Closure), NULL, NULL)

7 /var/www/html/owncloud/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php(135): GuzzleHttp\Message\FutureResponse::proxy(Object(GuzzleHttp\Ring\Future\CompletedFutureArray), Object(Closure))

8 /var/www/html/owncloud/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php(132): GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))

9 /var/www/html/owncloud/3rdparty/react/promise/src/FulfilledPromise.php(24): GuzzleHttp\RequestFsm->GuzzleHttp{closure}(Array)

10 /var/www/html/owncloud/3rdparty/guzzlehttp/ringphp/src/Future/CompletedFutureValue.php(55): React\Promise\FulfilledPromise->then(Object(Closure), NULL, NULL)

11 /var/www/html/owncloud/3rdparty/guzzlehttp/guzzle/src/Message/FutureResponse.php(43): GuzzleHttp\Ring\Future\CompletedFutureValue->then(Object(Closure), NULL, NULL)

12 /var/www/html/owncloud/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php(135): GuzzleHttp\Message\FutureResponse::proxy(Object(GuzzleHttp\Ring\Future\CompletedFutureArray), Object(Closure))

13 /var/www/html/owncloud/3rdparty/guzzlehttp/guzzle/src/Client.php(232): GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))

14 /var/www/html/owncloud/3rdparty/guzzlehttp/guzzle/src/Client.php(192): GuzzleHttp\Client->send(Object(GuzzleHttp\Message\Request))

15 /var/www/html/owncloud/lib/private/http/client/client.php(122): GuzzleHttp\Client->get('https://www.own...', Array)

16 /var/www/html/owncloud/test.php(8): OC\Http\Client\Client->get('https://www.own...')

17 {main}

Fedora 22
Curl: 7.40.0-5
PHP: 5.6.10-1

HTTP Status: 200
HTTP Status: 400

In spite of the test results, I still get an admin page that claims the server cannot connect to the internet. From test.php I get

HTTP Status: 200
HTTP Status: 301

PHP 5.5.9-1ubuntu4.11
Ubuntu 14.04
curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3

Form test.php I get:
HTTP Status: 200
HTTP Status: 400

System: Clearos 6.6.1 / Rhel
php 5.4.42-1.el6.remi
curl 7.19.7-40.el6_6.4

I can't download / install apps getting:

Client error response [url] https://apps.owncloud.com///...zip [status code] 400 [reason phrase] Bad Request

@Lebernd

I am getting the same error when installing apps from the appstore as well. I filed this issue for it: https://github.com/owncloud/core/issues/17456

RHEL7/Centos7/Fedora
compiled (src.rpm) latest php 5.6.10 and curl 7.43.0
libcurl under RHEL7/Fedora is compiled with nss by default (not openssl) and returns HTTP 400
compiled --with-ssl (openssl) returns HTTP 301
Does not seem to be a php problem

standard curl 7.29 binary also gets HTTP 301 when called from cmdline

That's most propably an issue caused RHEL/CentOS and their love for nss. I guess there is some tuning of the curl options required to enable the proper TLS version and/or ciphers.

I already did some testing but haven't found a working solution yet, maybe this get's somebody on the right track to fix it.

I think we see two different problems here.
One affects RHEL/CentOS and gives a status code of 400 in test.php.
The other problem affects all distributions and gives a status code of 301 in test.php but still shows "missing internet connection" in the backend (and fails to add apps)..

At 3rdparty/guzzlehttp/ringphp/src/Client/CurlFactory.php:428:
$value expands to '@'. This confuses curl. I set it to '' (empty string) and app download works again. Not sure how to fix it correctly.

I found a solution on a centos6 setup, but may be applicable to other centos/fedora distrib. Main problem was the version of libcurl.

From :
http://stackoverflow.com/questions/26452755/php-curl-with-nss-is-probably-using-sslv3-insted-of-tls-when-connecting-to-htt

"That's an interesting problem.

If you query SSLLabs for this site you will see, that it only supports various ECDHE-ECDSA-* ciphers and no other ciphers. But, in the version history of curl you will find a bug with ECC ciphers and the NSS library (which you use) which is only fixed in curl version 7.36 "nss: allow to use ECC ciphers if NSS implements them".

Since you are using curl 7.19.7 your curl is too old to use the necessary ciphers together with the NSS library. This means you need to upgrade your curl library."

From :
http://stackoverflow.com/questions/28495444/how-to-upgrade-php-curl-to-version-7-36-0
"Use the city-fan repo ( part of the curl mirror http://curl.haxx.se/download.html#LinuxRedhat)
rpm -Uvh http://www.city-fan.org/ftp/contrib/yum-repo/city-fan.org-release-1-12.rhel6.noarch.rpm
yum install libcurl

You can check for the latest version here: http://www.city-fan.org/ftp/contrib/yum-repo/rhel6/x86_64/repoview/city-fan.org-release.html

This currently updates curl from 7.19 to 7.40"

The city-fan repo version is actually 1-13.
So for centos6
rpm -Uvh http://www.city-fan.org/ftp/contrib/yum-repo/city-fan.org-release-1-13.rhel6.noarch.rpm
yum install libcurl

test.php gives now :
HTTP Status: 200 HTTP Status: 301

I have no warning anymore concerning internet access, and apps installation from store is ok.

Then please open an bugzilla ticket for RHEL/Fedora.

Are you sure the city-fan.org curl version on rhel6 is built with nss?
The srpm from city-fan seems to compile it with openssl, not nss for rhel <=6:
http://www.city-fan.org/ftp/contrib/yum-repo/rhel6/source/curl-7.43.0-1.0.cf.rhel6.src.rpm
# Build with nss rather than OpenSSL for Fedora 16 onwards unless OpenSSL is requested
# (older distributions don't have recent enough nss versions)
%global nss_ok %([ "%{__distinit}" == "fc" -a %{__distvers} -gt 15 -o "%{__distinit}" == "rhel" -a % {__distvers} -gt 6 ] && echo 1 || echo 0)

Did you notice HTTP 400 does not occur if the urls are called separately?

php test.php
echo "HTTP Status: ".doCurl("https://owncloud.org")."\n";
echo "HTTP Status: ".doCurl("https://www.owncloud.org")."\n";

HTTP Status: 200
HTTP Status: 400
--
php test.php
echo "HTTP Status: ".doCurl("https://owncloud.org")."\n";
// echo "HTTP Status: ".doCurl("https://www.owncloud.org")."\n";

HTTP Status: 200
--
php test.php
// echo "HTTP Status: ".doCurl("https://owncloud.org")."\n";
echo "HTTP Status: ".doCurl("https://www.owncloud.org")."\n";

HTTP Status: 301

The HTTP 400 is returned because certificate verification fails, it does not happen with (CURLOPT_SSL_VERIFYPEER, 0). So why does it only fail when both urls are called subsequently?

The only difference I can see is that NSS is only initialized on first request, perhaps something is cached erroneously?

Connected to owncloud.org (50.30.33.236) port 443 (#0)
Initializing NSS with certpath: sql:/etc/pki/nssdb
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none

Connected to www.owncloud.org (50.30.33.236) port 443 (#1)
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none

You're right, it is built with openssl not nss :

curl --version

curl 7.43.0 (x86_64-redhat-linux-gnu) libcurl/7.43.0 OpenSSL/1.0.1e zlib/1.2.3 c-ares/1.10.0 libidn/1.18 libssh2/1.6.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets Metalink

The original problem is obviously related to nss...

Some other results that I have noted.
You get the error message, but install 3rd party app's work.
Tested with the "Calendar 0.7.1" app.

This also happens with cmdline curl.
See https://bugzilla.redhat.com/show_bug.cgi?id=1241172

@maelange https://github.com/owncloud/core/issues/16255#issuecomment-119531656 is working for me.

Hello everyone, seems like I can't get it to install..

I run CentOS 7, so I navigated to RHEL7
http://www.city-fan.org/ftp/contrib/yum-repo/rhel7/source/

EDIT 3:

Check out this string of dependency fails and let me know what you come up with.


[root@u16585982 ~]# rpm -Uvh http://www.city-fan.org/ftp/contrib/yum-repo/rhel7/x86_64/curl-7.43.0-1.0.cf.rhel7.x86_64.rpm
Retrieving http://www.city-fan.org/ftp/contrib/yum-repo/rhel7/x86_64/curl-7.43.0-1.0.cf.rhel7.x86_64.rpm
warning: /var/tmp/rpm-tmp.y6EaRu: Header V3 DSA/SHA1 Signature, key ID b56a8bac: NOKEY
error: Failed dependencies:
libcurl(x86-64) = 7.43.0-1.0.cf.rhel7 is needed by curl-7.43.0-1.0.cf.rhel7.x86_64

[root@u16585982 ~]# rpm -Uvh http://www.city-fan.org/ftp/contrib/yum-repo/rhel7/x86_64/libcurl-7.43.0-1.0.cf.rhel7.x86_64.rpm
Retrieving http://www.city-fan.org/ftp/contrib/yum-repo/rhel7/x86_64/libcurl-7.43.0-1.0.cf.rhel7.x86_64.rpm
warning: /var/tmp/rpm-tmp.dSuLkr: Header V3 DSA/SHA1 Signature, key ID b56a8bac: NOKEY
error: Failed dependencies:
libcurl = 7.29.0-19.el7 is needed by (installed) curl-7.29.0-19.el7.x86_64

So what I am gathering from this is, I need Curl 7.43 to get Libcurl 7.43, and the other way around.

What can I do?

NOTES: I had to install

Libmetalink from the following URL

http://rpmfind.net//linux/RPM/fedora/devel/rawhide/x86_64/l/libmetalink-0.1.2-8.fc23.x86_64.html

Gents,

Are we any closer to getting this solved?

J.

TactiveLearning, what you can do to upgrade curl(just did this on my CentOS 7):

1) create a new file /etc/yum.repos.d/city-fan.repo
2) Paste the following contents:
[CityFan]
name=City Fan Repo
baseurl=http://www.city-fan.org/ftp/contrib/yum-repo/rhel7/x86_64/
enabled=1
gpgcheck=0

3) type:
yum clean all
yum install curl
4) And it's done.

No you'll have curl 7.43...unfortunately the problems remain in my case. The test LukasReschke posted still returns HTTP 400 in the second line.

The problems started in my case when upgrading to 8.1( php occ upgrade ) and these same 400 errors where thrown when it wanted to upgrade an app(Bookmarks I believe).
Then I noticed the "Server is not connected to the internet message" in the admin page, and found I could not install any apps.

Edit: this RHEL7 version of curl 7.43 is also compiled against NSS instead of OpenSSL(where the RHEL6 version seems to be compiled against OpenSSL).

Edit2:
Seems to me this is a pretty big deal. So unless you'll compile curl from source yourself: OwnCloud 8.1 wont work very well on RHEL7 based distributions(In fact, upgrade will probably fail if you won't disable all apps).

curl uses nss (instead of openssl) on centos7/rhel7/fedora. Unfortunately there is a bug in nss with certificate verification that prevents owncloud from functioning properly. It has been fixed but it may take a while until rpm updates are released.

https://bugzilla.redhat.com/show_bug.cgi?id=1241172

The best would be to wait for the rpm updates. If it's really urgent, you can try the curl rpms I made for testing (compiled with openssl, x86_64 only):

cd /tmp
wget http://centos7.gcore.biz/tmp/curl-7.43.0-1.el7.centos.x86_64.rpm
wget http://centos7.gcore.biz/tmp/libcurl-7.43.0-1.el7.centos.x86_64.rpm
yum install curl-7.43.0-1.el7.centos.x86_64.rpm libcurl-7.43.0-1.el7.centos.x86_64.rpm

yum will detect libmetalink dependency and install it.

Please note you should remove these rpms and use the rhel/centos updates when available!

Thank you so very much @gcoretech & @Yomark1 you guys are awesome :)

I am using Gcoretech's fix for now.

Sorry for this noobish question, but how can I get informed about the next release of this RPM?

EDIT:

Confirming for @Gcoretech :: The fix works and was rid of my issue :) Amazing work man. :+1:

The curl rpms above are just a temporary fix using openssl ... it's really a problem with nss not curl.

[root@host ~]# rpm -q nss
nss-3.19.1-3.el7_1.x86_64

You can do a yum check-update once a day and if there is a newer nss version, apply the update.
Then do yum downgrade curl libcurl to get the original version that receives the usual rhel/centos updates.

Awesome, thank you again @Gcoretech :) :+1:

I'm sorry, but how does solving this for CentOS fix the OP problem (and mine) on Ubuntu 14.04? I still get the following (see above for test.php output):

screen shot 2015-07-14 at 10 44 25 am

Did I miss something?

I can confirm this bug since the update on OC 8.1 on Debian 7 with PHP 5.6.9-1 and nginx 1.9.2

@redfave @koehn I think there are currently three issues mixed within this thread:

  1. Bug in curl with nss lib on CentOS/RHEL (https://github.com/owncloud/core/issues/16255#issuecomment-119531656, Bugreport in https://bugzilla.redhat.com/show_bug.cgi?id=1241172)
  2. Bug in PHP itself: https://bugs.php.net/bug.php?id=67639
  3. Additional unknown issue on other systems

For 3. there are some things to check:

  • Check that you don't have an 'has_internet_connection' => false, in your config.php
  • Check that you don't have copied over the config.sample.php to config.php and using some of the default empty proxy settings there.
  • Check that your system is able to access https://www.owncloud.org via 443/tcp (outgoing)

@RealRancor

Reckon it's 2 or 3.

  • No, I don't have 'has_internet_connection' => false, in my config.php. Altering it to true doesn't have an effect
  • Neither I just copied config.sample.php into config.php.
    Here is mine:
<?php
$CONFIG = array (
  'instanceid' => 'oc27842ea38c',
  'passwordsalt' => 'e6942e6e66fe933d67c34ea693a556',
  'trusted_domains' =>
  array (
    0 => 'myhomeaccess.flnet.org',
  ),
  'datadirectory' => '/var/www/owncloud/data',
  'overwrite.cli.url' => 'https://myhomeaccess.flnet.org',
  'dbtype' => 'sqlite3',
  'dbhost' => 'localhost',
  'version' => '8.1.0.8',
  'installed' => true,
  'forcessl' => true,
  'theme' => '',
  'trashbin_retention_obligation' => 90,
  'maintenance' => false,
  'secret' => 'dfd66811e9a7812476f83897f1a3f5350f47e225dcbafb252aa917ad3b5c5542281b1168111b322f4a2dfc5fcfc642ab',
  'loglevel' => 1,
  'memcache.local' => '\\OC\\Memcache\\APC',
  'asset-pipeline.enabled' => true,
  'appstore.experimental.enabled' => true,
);
  • Yes, the server has access to owncloud.org on port 80

android@localhost:~/Desktop$ telnet owncloud.org 80 Trying 50.30.33.236... Connected to owncloud.org. Escape character is '^]'.

as well as on port 443

android@localhost:~/Desktop$ telnet owncloud.org 443 Trying 50.30.33.236... Connected to owncloud.org. Escape character is '^]'.

Same exact issues. Centos 6 with the repo's all set up right. Didn't copy the config over just a standard config. Yum doesn't work anymore and will only attempt to use ipv6 even though its disabled on the server.

Yes I did those checks. I can't contact the server on port 443 because I don't have telnet installed nor can I install it because yum is broken. I could install it another way but...

I see the NSS thing is fixed but I don't know if its been pushed to yum and I couldn't upgrade anyway. Are there any rpm fixes?

Are there any rpm fixes?

Probably something you could ask the CentOS community

The fix hasn't even hit Fedora yet so I would guess there aren't any packages for CentOS

I used the rpm's from above (centos7) and the message is gone.

The patch found in:
https://bugzilla.redhat.com/show_bug.cgi?id=1104597

fixes the problem for fedora 22 as well. Too bad there aren't official rpm available yet.

I was able to compile curl 7.43 from source at http://curl.haxx.se using
./configure --enable-tls-srp --enable-ldaps --enable-ldap
make install
and adding the line
LD_LIBRARY_PATH=/usr/local/lib
to the appropriate system environment file for your web server such as
/etc/sysconfig/httpd
This way I was able to fix the problem without disturbing the rpms and dependencies.

So shouldn't there be a recommendation from the Owncloud community to advise against using Centos as of now until its sorted or there is an actual permanent fix? I tried recompiling curl as well as many other dozens of solutions without any luck.

You say you recompiled curl and it didn't work? Did you try the test case above outside of owncloud for testing?

@Lonecrowe oC 8.1.1 shows the messages what to do in the admin section like seen here:

https://doc.owncloud.org/server/8.1/admin_manual/configuration_server/security_setup_warnings.html#outdated-nss-openssl-version

Because of a bug in one single library its probably a little bit overkill to advise against a whole distribution.

Generally speaking, a lot of the stuff _should_ work even with older and buggy NSS. We employed workarounds for installing apps, if that with 8.1.1 does not work then please file a detailled issue. The more information the better.

However, there are problems left. So in rare cases where you do a Server-to-Server share to different instances on the same server using SNI this will lead to problems. There are some others, but as a regular user you are not likely to experience a lot of them.

Using CentOS and RHEL is completely fine. While it would be better that they update their stuff this is not completely dangerous.

As we now have a check and also mitigated some other issues I'm going to close this.

Thank you @dpackman. Your fix worked perfectly for me!

So what's the proposed fix now? I'm still experiencing this on Arch with curl 7.43.0-1 and nss 3.19.2-2

@Chais file a bug at https://bugs.archlinux.org/ mentioning that this https://bugzilla.redhat.com/show_bug.cgi?id=1104597 patch fixes the problem for fedora 22 (well maybe, if you can, try to patch and recompile nss:-) ), the arch guys are usually very fast to fix things.. I don't understand why RedHat did not merge the patch at least in testing. Maybe there isn't enough people complaining :-)

I also got the admin message "this server has no internet conection...". OC Server 8.1.1

Result from the above PHP/cURL test (seems ok):
HTTP Status: 200
HTTP Status: 301

My system is Debian stable 64 bits.

Apache

Server version: Apache/2.4.10 (Debian)
Server built:   Aug  1 2015 20:53:57
Server's Module Magic Number: 20120211:37
Server loaded:  APR 1.5.1, APR-UTIL 1.5.4
Compiled using: APR 1.5.1, APR-UTIL 1.5.4
Architecture:   64-bit
Server MPM:     prefork
  threaded:     no
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/etc/apache2"
 -D SUEXEC_BIN="/usr/lib/apache2/suexec"
 -D DEFAULT_PIDLOG="/var/run/apache2.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="mime.types"
 -D SERVER_CONFIG_FILE="apache2.conf"

PHP

PHP 5.6.9-0+deb8u1 (cli) (built: Jun  5 2015 11:03:27)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
    with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2015, by Zend Technologies

cURL

curl 7.38.0 (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1k zlib/1.2.8 libidn/1.29 libssh2/1.4.3 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL libz TLS-SRP

@RealRancor Thanks! It was a missing ca-bundle.crt

Did the "upgrader app" path from latest 8.0 version (waited until 8.1.1, skipped 8.1.0 as I had encryption enabled in the past).

@sargue Yes, the updater is currently failing to copy this ca-bundle.crt if upgrading from oC 8.0.x to 8.1.x: https://github.com/owncloud/updater/issues/164

FYI for anyone following this issue.

Fedora 22/23 has had the updated curl-7.40.0-7.fc22/23 package pushed out to the stable repo 9 days ago (https://bugzilla.redhat.com/show_bug.cgi?id=1104597)

RHEL/CentOS 7.1 has an updated package in the testing repo (https://bugzilla.redhat.com/show_bug.cgi?id=1241172)

To fix the problem on Ubuntu 13.04 or 14.04, you can actually follow these instructions

  • Use this custom PPA to update your cURL
  • Fetch the latest ca-bundle.crt by executing wget https://raw.githubusercontent.com/owncloud/core/stable8.1/config/ca-bundle.crt in your config folder.

This made things work for me again.
Additionally anyone upgrading should check for empty or invalid proxy settings in their config.php

I had the ca-bundle.crt, but downloading it again as Fohlen commented solved my problem.
Ubuntu 14.04 with default php.

This helped me on Debian 7, too!

I just got this error again after several years of not seeing them having tested some of the above fixes.
Getting the internet connection-message on both CentOS 6 and 7.
The COS7 server is a recent fresh install with Owncloud.
The COS6 is an oldie.
Both servers run the latest OC v10.0.3.3 software.
Has something changed?

Same here on v10.0.4, most interesting this is on a Debian VM, upgraded to Buster, so all packages are more recent than on my other systems (Jessie + Stretch), where the error does not show up.
Use MariaDB + Apache + mod-php + redis-server with it.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings