[4.1.0.23][4.0.1.45] Browser URL with ':<port>' suffix fails as invalid, i.e. non-standard port used https://<host>:<port> where port is e.g. 1443

Bug Reports
,
#1

REPRODUCIBILITY (% or how often): 100%
BUILD ID = OS VERSION (Settings > About product): 4.0.1
HARDWARE (XA2, Xperia 10…): Jolla Tablet (and on fp2 Version 3.4.0)
UI LANGUAGE: german
REGRESSION: (compared to previous public release: Yes, No, ?): no

DESCRIPTION:

the jolla browser did not recognise 'https://domain:port/ as valid url.

PRECONDITIONS:

none

STEPS TO REPRODUCE:

  1. open jolla browser
  2. type URL with port extention

EXPECTED RESULT:

Webpage should be loaded

ACTUAL RESULT:

The URL is not valid and cannot be loaded.

ADDITIONAL INFORMATION:

(Please ALWAYS attach relevant data such as logs, screenshots, etc…)
not possibe no screenshot on tablet

UPDATE 2021-02-19:
I setup a Website with the following URL:
https://mobydick.spdns.de:4443/

The picture shows that it is working.
The server is behind a firewall and only the port 4443 is open and redirected to the internal Website.

Webpage
Webpage860×389 52.6 KB

3 Likes
[4.1.0.23][4.0.1.45] EA Sailfish Browser does not open HTTPS with non-standard port
[4.1.0.23][4.0.1.45] EA Sailfish Browser does not open HTTPS with non-standard port
[4.1.0.23][4.0.1.45] EA Sailfish Browser does not open HTTPS with non-standard port
#2

When I try https://forum.sailfishos.org:443/ it is working for me. What url exactly you are trying?

#3

I do confirm!
(another blocker to update my daily driver :frowning: )

Going with well known default ports
http --> 80
https-- > 443
will work but that’s it.
If you use a different port you get above mentioned error!
(to avoid misunderstanding: of course it is not about https://forum.sailfishos.org:444 or something not available but a well reachable own server listening on a free defined port)
On SFOS 3.2.1.20 browser (and earlier) it worked/works.

2 Likes
#4

@karry and @peterleinchen - i updated my bug report (and setup a ‘simple’ ssl Website for testing :-)).
Hope this helps to fix the bug …

1 Like
#5

Yes, makes it clear as kloßbrühe. :wink:

And as expected same result
4.0.1.48 --> the address isn’t valid
3.2.1.20 --> tick mark, works

#6

https://mobydick.spdns.de:4443/ results in ‘Warning: Potential Security Risk Ahead’

so, maybe a letsencrypt cert?

Calling it up on 3.4.xxx also results in a no go for me. But It’s a no go on any system for me :slight_smile:

#7

@poetaster: Now you’re mixing two things.
This bug report is about URL validation, not SSL certificate validity.

2 Likes
#8

Well, since one browser ‘refuses’ to connect, who knows why the other doesn’t connect. I’m not confusing anything. I’m being critical of setting up a test scenario that may cause errors that have nothing to do with port handling. But I also set up letsencrypt everywhere as a habit.

You may have noticed that some browsers have begun to limit how you enter protocol before you even enter enter?

And I said, It’s a no go on 3.4, confirming the bug report. Confusing?

#9

It’s a selfsigned cert, so the warning is correct.
If you install the root certificate on your system (as i’ve done) the ‘Warning: Potential Security Risk Ahead’ vanish :wink:.

But anyway the error ‘… invald URL …’ is a bug.
Using a URL with ‘domain:port’ on a nextcloud account works as expected, so is is a bug on the browser handling …

1 Like
#10

Jeez, guys. I understand this. But testing software demands reducing, not increasing the complexity of the test scenario.

And I actually don’t have time to waste, so would like for the errors to be tested to be limited to those which are errors and not insufficient test scenarios.

#11

By comparison, Webpirate on Volla and FP2 opens with casual ‘accept self signed’ message.

#12

And a question. I’m ONLY running 3.4. I was under the impression that 4.x has a ‘different’ browser. Is this correct?

In which case, we need two bug reports against two browsers/components.

#13

In general that’s a good approach but to the matter at hand not relevant. We’re only cluttering the bug report… somebody gotta read this for internal tracking over at Jolla’s side. so let’s keep it dry and boring but technically relevant

#14

Understood. So it’s the same component in 3.4 and 4 and I should stop looking at the source (for instance as a dev in the context of:SailfishOS::WebEngine)? Looks like the bug report ist for 4.0.1

#15

On FP2 version 3.4.0 (community port) it’s the same behaviour.

I also setup a Website without ssl (port 4080) - but this is not helpfully because the the jolla Webbrowser automatically replace the http with https - the same a firefox does (this is stupid - and could not work on URLs with ‘:port’ because ssl always use an other port as nonssl …).
Google chrome :roll_eyes: did a better job here.

#16

I found this a bit confusing since you reported for 4.0.1 but also mentioned 3.4. I tested two ports 3.4 to confirm your finding. I guess it’s a bug in the webview components that begins in 3.4 and carries on to the 4.0.1 and new gecko parts?

#17

@poetaster, sorry for confusing you :blush:.
I’d missed to set the correct flags and did not fill the bug report for all devices i have.
The bug occurs on the following devices (as far as i cat try):
Jolla Tablet Version 4.0.1
Gemini PDA Version 4.0.1 (SaifishX from Jolla)
Fairphone 2 Version 3.4.0 (Community Port fom mal)

As @peterleinchen wrote on 3.2.1 it seems to work. So you are right - beginning with 3.4.0 there are new gecko parts and i looks like that all devices with 3.4.0 and above should have the problem.

It seems that the second problem about replacing http with https also comes with this new parts because native firefox (on my debian) also have this feature/bug.
The automatic switching from nativ (http) to ssl (https) protocol will not work on all Websites (especially on ‘privat’ Websites behind firewalls) with non standard ports.

1 Like
#18

Not really. It’s about a wrong error message. URL validation works just fine as you can see by running tcpdump before opening the browser, e.g.

tcpdump -i any -s 0 -w /tmp/dump.pcap port 4443

If you analyze the dump with wireshark, you will see the phone connecting, i.e. the URL has been properly parsed, but the TLS handshake fails. And here the browser generates a misleading error message.

Trying https://eierkopp.ddnss.org:1443/ instead works at least for me. And that’s with a LetsEncrypt cert.

3 Likes
#19

Ah, fun. With 3.4 on community port FP2 (and 3.4 on the Vollaphone community port) I get an http auth request … what are the credentials :slight_smile:

Is that progress? In any case, I can use an arbitrary (high enough) port number. I’m not getting any error message :slight_smile:

1 Like
#20

Yes, confirm martinh.

On 4.0.1 and now also 4.1.0 I can reach the eierkopp and get asked for credentials.
But with self-signed certs (the one provided by gabs5807 and my own test server) I get

Screenshot_20210514_001_1
Screenshot_20210514_001_11080×1079 37.1 KB