After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 770532 - following redirect fails when server closes connection unexpectedly
following redirect fails when server closes connection unexpectedly
Status: RESOLVED OBSOLETE
Product: epiphany
Classification: Core
Component: Backend
3.20.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-08-29 07:57 UTC by Sander Hoentjen
Modified: 2018-08-03 20:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sander Hoentjen 2016-08-29 07:57:30 UTC
I have an issue with a strange kind of redirection. The webserver detects when a non-TLS connection is made to a TLS port, and reponds with a Location-header. It then seems to abruptly terminate the connection.

This works fine from a user-prespective in all the browsers I have tested: various (probably all) version of IE, Firefox, Chromium, Safari, elinks, curl. It doesn't work with epiphany.

Curl output:
================================================
~]$ curl -v -L http://141.138.169.214:2223/
*   Trying 141.138.169.214...
* Connected to 141.138.169.214 (141.138.169.214) port 2223 (#0)
> GET / HTTP/1.1
> Host: 141.138.169.214:2223
> User-Agent: curl/7.47.1
> Accept: */*
> 
< HTTP/1.1 302 Found
< Server: DirectAdmin Daemon v1.50.1
< Location: https://s214.webhostingserver.nl:2223
< x-use-https: yes
< Content-type: text/html
* no chunk, no close, no size. Assume close to signal end
< 
* Closing connection 0
* Issue another request to this URL: 'https://s214.webhostingserver.nl:2223'
* Rebuilt URL to: https://s214.webhostingserver.nl:2223/
*   Trying 141.138.169.214...
* Connected to s214.webhostingserver.nl (141.138.169.214) port 2223 (#1)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* ALPN/NPN, server did not agree to a protocol
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* 	subject: CN=*.webhostingserver.nl,OU=EssentialSSL Wildcard,OU=Domain Control Validated
* 	start date: Jan 15 00:00:00 2015 GMT
* 	expire date: Feb 17 23:59:59 2018 GMT
* 	common name: *.webhostingserver.nl
* 	issuer: CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
> GET / HTTP/1.1
> Host: s214.webhostingserver.nl:2223
> User-Agent: curl/7.47.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: DirectAdmin Daemon v1.50.1 Registered to Antagonist
< Set-Cookie: session=; path=/; expires=Tue, 30 Aug 2016 07:54:24 GMT; secure; HttpOnly
< Connection: close
< Cache-Control: no-cache
< Pragma: no-cache
< X-DirectAdmin: unauthorized
< Content-Type: text/html
< 
<html>
<head>
<snip>
================================================
epiphany output on console:
================================================
~]$ epiphany 

** (epiphany:13425): CRITICAL **: load_failed_cb: assertion '(error->domain == WEBKIT_NETWORK_ERROR) || (error->domain == WEBKIT_POLICY_ERROR) || (error->domain == WEBKIT_PLUGIN_ERROR)' failed
================================================
Comment 1 Michael Catanzaro 2016-08-29 12:17:04 UTC
(In reply to Sander Hoentjen from comment #0)
> ** (epiphany:13425): CRITICAL **: load_failed_cb: assertion '(error->domain
> == WEBKIT_NETWORK_ERROR) || (error->domain == WEBKIT_POLICY_ERROR) ||
> (error->domain == WEBKIT_PLUGIN_ERROR)' failed

So this is probably a symptom rather than the underlying cause, but it's a great place to start. The question here is: is the assert wrong, or is it wrong that we bubble up some other type of error? This is not the first time we've hit this assert. I'll try to investigate (eventually).

The underlying bug is probably in WebKit or libsoup somewhere.
Comment 2 Sander Hoentjen 2016-08-29 13:38:43 UTC
If there is anything I can do to help, let me know. Just know that I am not a developer :)
Comment 3 Carlos Garcia Campos 2016-08-29 16:25:59 UTC
I haven't look at the problem in detail, but that assert has been wrong for some time, it doesn't cover all the cases, it needs to be checked again or simply removed.
Comment 4 Michael Catanzaro 2016-08-29 18:47:12 UTC
I removed the assert. Once you get a new build, you should see a proper error message to give us a hint what's going wrong here. Unfortunately I'm testing WebKit trunk which is broken ATM (crashes when displaying any page) so I won't check it myself right now.
Comment 5 Sander Hoentjen 2016-08-30 07:12:36 UTC
I build Fedora 24's epiphany with your patch. Now when I try the page it says:
====================
Oops! Unable to display this website.
The site at “http://141.138.169.214:2223/” seems to be unavailable. The precise error was:

Error receiving data: Connection reset by peer

It may be temporarily unavailable or moved to a new address. You may wish to verify that your internet connection is working correctly.
====================
No output on the console this time.
Comment 6 GNOME Infrastructure Team 2018-08-03 20:51:26 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/epiphany/issues/325.