When I click links in lemmy comments that explicitly include http in the url, the resulting page is always https. To me, the preferred behavior would be to default to https if no protocol is specified, but to respect the user’s preference if given.
Most of the time, there is no downside to changing to https, but some sites will result in an error if they don’t properly support https (I’ve encountered this when incorrectly typing a url before, but as it was not recent I don’t recall the details), and in rare cases the same domain name may serve different content on http vs https, making the ability to specify when linking desirable.
For example, http://xkcdsw.com is an archive of fan-edited comics, while https://xkcdsw.com is some kind of crypto site. While obviously that’s dodgy on the site end, it’s also strange to be completely unable to link the former without telling people to manually remove the s.
Is this redirecting happening on the app level, or the instance level, or something else? It’s not unique to me, as I was first alerted to it by replies that were confused at my links not going where I said they went.
It looks like Jerboa is forcing HTTPS. It’s using the Markwon library for parsing markdown, and a custom
ForceHttpsPlugin
is installed: https://github.com/LemmyNet/jerboa/blob/19be714fe08eaff6d2f616aa3da1b82df81a1d84/app/src/main/java/com/jerboa/ui/components/common/MarkdownHelper.kt#L93.Aha, thanks! I guess that concludes this thread, as I don’t really expect to get a dev chiming in explaining why.
It’s not my preferred way of handling it but I don’t have the energy to make a fuss. I guess if I click a link that needs to be http, I’ll copy it to a browser, and if I post one I’ll remind others to do the same. Probably won’t come up often enough to care about.
At least you’ve satisfied my curiosity as to what was going on 😀
Edit: I was repeatedly told while trying to post this comment that the request timeout had expired. When the error stopped appearing, I had posted 4 copies of this message. I have deleted them but I apologize if they still spam your inbox as [deleted] or something.
Jerboa forces HTTPS for images (Markwon plugin) because android doesn’t allow to load http due to cleartext. I can disable this for older Android version but not in newer Android. There is a good reason for this as its much less secure. So instead I chose to rewrite http to https for links in markwon
https://developer.android.com/privacy-and-security/risks/cleartext
Actually Jerboa rewrites all http links to https. Originally it was because of cleartext, it wouldn’t load http images. But then I decided all links should be rewritten to http for security. If it might be too troubling I could change this but imo all sites should support https
For example, http://xkcdsw.com is an archive of fan-edited comics, while https://xkcdsw.com is some kind of crypto site.
That’s not how URLs work. If that’s the behavior you’re experiencing, you likely have been the victim of malware/a virus.
The first part of the URL is the scheme, which indicates the protocol that the browser must use to request the resource (a protocol is a set method for exchanging or transferring data around a computer network). Usually for websites the protocol is HTTPS or HTTP (its unsecured version). Addressing web pages requires one of these two, but browsers also know how to handle other schemes such as mailto: (to open a mail client), so don’t be surprised if you see other protocols.
Did you click the links before telling me that’s not how it works though? Other people are reporting the same result. I also get the same result on both my phone and desktop. Seems like two clicks would be less trouble than finding sources to back up a condescending and inaccurate response.
Here is some information supporting the fact that URLs can work that way (although the two links you quoted but did not click on from my original post already demonstrate that): https://superuser.com/questions/792202/different-website-at-https-then-at-http
Edit: bear in mind that to reproduce the behavior, you might need to type the http into your browser manually if you are using jerboa.
I mean technically it’s possible to have different sites on http:// and https://, since the conventional ports are different (80 and 443), but it’d be a pretty weird thing to do.
Edit: I just visited the links and the http:// one does indeed go to an xkcd-style site, while https:// has some dogecoin tracker with a broken SSL certificate.
Edit again: the SSL certificate is for dogecoinaverage.com, so I have a feeling this person just misconfigured their nginx or Apache instance.
Yet another edit: the maintainer’s Mastodon is linked on the xkcd site, which links to their GitHub, which includes the source for the Dogecoin average site: https://github.com/Two9A/dogecoin-average. Definitely just a weird misconfiguration.
Thanks for looking into this thoroughly, and for correctly noting what’s causing the situation with my specific example.
I contacted Two9A about his weird configuration before I made my original post, but have yet to get a reply from them. The specific example of xkcdsw is a separate issue unrelated to jerboa.
My main question was what is causing http links opened on lemmy through jerboa to redirect to https links - whether that is being done by the app or the instance or what. If it is the intended behavior of the jerboa app, I’m curious as to why it doesn’t leave the protocol up to the commenter.
The letters are the front are the protocol you’re accessing the site through. http is for unencrypted webpages and https is for encrypted web pages.
For a webpage to be encrypted they need a certificate from a certificate authority which verifies the person who asks for the certificate actually runs the server they want the certificate for. The page you link doesn’t have a certificate and so the web page cannot be accessed with https. Your browser should tell you a secure connection could not be made with the server. That’s what it does for me.
If you’re getting a different page you probably have a virus which is serving fake certificates to your browser and redirecting your traffic to a scam server. You probably shouldn’t be typing passwords into your browser until you fix that.