Opened 6 years ago

Closed 10 months ago

#5127 closed enhancement (fixed)

Non HTTPS-Links: Share links and link to wiki, when being on the HTTPS page

Reported by: ToB Owned by: rails-dev@…
Priority: minor Milestone:
Component: website Version:
Keywords: https Cc:


  • When trying to share an URL, the links are always HTTP links instead of HTTPS Links: -> right side -> share (link, HTML; affects: long link, short link and html-iframe link.
  • -> wiki link (at least in the DE localized version) links to HTTP instead of the HTTPS version

In principle, one can use, e.g., <a href="//"> and then the browser should use the same protocol (HTTP vs HTTPS) as for that page, but I don't know how widely it is supported.

Change History (9)

comment:1 Changed 6 years ago by Tom Hughes

Resolution: wontfix
Status: newclosed

We have made no effort to make external links preserve the protocol, nor do I have any particular plan to do so - it would be a huge amount of work for very minimal gain.

comment:2 Changed 6 years ago by aseerel4c26

Tom, Tom... the old issue. Then please keep this bug open (it even is only filed as "enhancement"!). Not a "Tom-only" bugtracker, is it? Are you trying to get a good reputation at GCHQ? ;-) Then please just ignore those security and privacy related bugs. It is okay if you are giving a sh.. about privacy, but please do not demand the same from all others. Don't get me wrong, I really appreciate all your hard work for OSM!

Last edited 6 years ago by aseerel4c26 (previous) (diff)

comment:3 Changed 6 years ago by aseerel4c26

Resolution: wontfix
Status: closedreopened

comment:4 Changed 6 years ago by Tom Hughes

The problem is this bug has no defined scope - no end point when it could ever be closed.

I'm not even sure there is any logic in a theory that an page loaded over https should only link to other pages over https. Surely if you believe in "https everywhere" you should be arguing that all out links to sites which support https should be in https regardless of what protocol the source page was loaded over?

comment:5 Changed 6 years ago by aseerel4c26

Keywords: https added

I do not know of RFCs or something, but it is just good practise to use protocol-relative links if the target page is reachable via http and https. It even saves space. ;-)

What a page should not do is to open a page via http if the clicked link shows https, because the user might prefer to not open the page via http.

Scope? Hmm, its end is a bit blurry, yes. But the it mentions a few specific, prominent high-traffic links which should be changed. After this bug could be closed. On a second thought: if one would e.g. search through all interface code and replace all http links then this bug would be finished completely.

comment:6 Changed 6 years ago by Tom Hughes

Go on then - I know you know where the source is.

Don't forget to make sure it works when pages are loaded locally from file URLs when that is relevant.

Oh and of course you'll have to work out how to deal with all the URLs that are embedded in the locale files.

Still think it's easy?

comment:7 Changed 6 years ago by aseerel4c26

Tom, yes, I know where the source is. And, no, I will not do any changes currently (first: time, second: github).

Did I say it is "easy"? I think I did not.

I do not understand why you are so pissed about this topic. :-( "Not invented here"? Well, maybe just because it is totally irrelevant in your POV. As said, then please just ignore those bugs.

comment:8 Changed 6 years ago by Tom Hughes

Because I view all these bugs as my "to do list" and I endeavour to stop it growing out of control.

A database of thousands of bugs that nobody ever does anything about is of no use to anybody - all it does is hide important issues in a lot of background noise.

comment:9 Changed 10 months ago by Andy Allan

Resolution: fixed
Status: reopenedclosed

Since this issue was created, OSMF has moved to https across all sites. I've identified that some of the translations are still using old links, and I've created to track this. But otherwise this is fixed.

Note: See TracTickets for help on using tickets.