3.0 downloadFile on Windows doesn't support https

[Vadim Peretokin]

Using downloadFile on Windows on an https url in 3.0.0-delta fails with: Unable to init SSL Context

Stephen reckons it is:

You are using Windows I take it? Seems that there might be an outdated or missing SSL Library, an admittedly old StackOverflow [http://stackoverflow.com/questions/14989135/qt-downloading-a-file-doesnt-work] post suggests that you might need libeay32.dll, libssl32.dll, ssleay32.dll from the OpenSSL project. Whether that is still relevant remains to be seen but it does seem that you cannot get the SSL subsystem up and running...

Original report: http://forums.mudlet.org/viewtopic.php?f=9&t=4728

[Stephen Lyons (slysven)]

Ah, I think I have located a more probably explanation: the code in TLuaInterpreter::downloadFile(...) that checks for a "https:" rather than a "http:" type download looks for the string in the DESTINATION FILE (in "_path") rather than in the SOURCE URL (in "_url") - it never sees it because it is looking in the wrong place! I am fixing this as part of overhauling all of the file downloading code to add the missing error detection and warnings thereof.

This will be an error on all OSes not just Windows.

[JulesK (juleskelworan)]

IRE has moved ALL of their downloadable map.xml files to https, meaning that those files are essentially invisible to Mudlet now. Please consider bumping up the priority of this bug. Thank you!

[Chris Leacy (cleacy1972)]

I just checked, and downloaded a file from google drive through https (using a recently built windows compile) - Looks like it was probably fixed and just never noted as such.

[JulesK (juleskelworan)]

Hrm, I guess the original problem was summarized as "there is this mudlet function called downloadFile and it doesn't play nicely with https". It sounds like that at least works now. However, the "map" button on the GUI, which is the only way to download a fresh map that mudlet will recognize, had been working fine, until IRE recently switched their map.xml files from http to https. I cannot just put a "good" map.xml file into the appropriate directory, either, as Mudlet does not recognize it. In short, maybe one of the most important, basic things many users will now have to do with https (just grabbing the game's latest map) isn't going to happen anymore unless this is fixed.

[Chris Leacy (cleacy1972)]

I have links posted in http://forums.mudlet.org/viewtopic.php?f=7&t=5712 to win32 and osx binaries I built from branch_30 about 5 months ago. Is the problem with the map button also occuring with either of them, or a newly compiled?

As a warning however btw - My posted versions are done from pr308, which was a major update to the mapper code and quite possibly might introduce other problems with the IRE maps.

[JulesK (juleskelworan)]

Yeah, you're right, Chris. You certainly can just download a file from an https location to an html page in your current profile directory with that downloadFile function thing. It worked for me too, after I fiddled a bit (I don't understand functions like that too well).

So, I guess that part is all good... but still, no maps from https :( I would rather not open an entirely new bug if I can avoid it, because I think it could take quite some time to gain traction. Hopefully someone sees this and a light bulb goes on as to why the map downloader isn't playing nicely with https.

[JulesK (juleskelworan)]

Ah, let me try that last one - I assume you mean this: https://github.com/Nyyrazzilyss/NyyLIB/raw/master/NyyLIB010e.zip

The map problem is with totally clean installs of Mudlet 3.0 (delta), and I was very careful to uninstall, and also to remove the .config directory, the Mudlet directory that is in AppData/Local, and the mudlet-data file that is created in the User's folder (I hope that is the right answer you were looking for). I also ensured that I enabled GMCP on the new install(s), and then restarted. I updated the mapper script... When I have had any sort of hiccups with maps in the past, the best fix has always been to just delete the map.xml file in my profile, along with the map folder containing the map.dat files (because Mudlet isn't always great about being able to overwrite). It had always worked like an absolute charm. Until yesterday... And Garryn from our game's admin mentioned that the map.xml files are not all on https sites and said that Mudlet may not be able to grab them (which does seem to be the case).

[JulesK (juleskelworan)]

Argh, they ARE all on https sites... I meant.

[Chris Leacy (cleacy1972)]

Not my script package no :P That's for the mud I play. I meant was the problem with the map button still happening with the win32 compile I had posted (https://github.com/Nyyrazzilyss/NyyLIB/raw/master/mudlet_w32_pr308.zip)

[Chris (chrismudlet)]

It's broken because the backend itself requests a http link:

https://github.com/Mudlet/Mudlet/blob/4f6a41d6c5f40fd8f01db91355ba029992b1f73c/src/dlgMapper.cpp#L223

[JulesK (juleskelworan)]

This may be a dumb, but I tried using this file (the https://github.com/Nyyrazzilyss/NyyLIB/raw/master/mudlet_w32_pr308.zip one) two ways.

First, I tried using it from the folder it was extracted to (although I had again deleted anything mudlet related beforehand). However, when I installed the new mudlet mapper (pretty sure the default is too old for all of this stuff anyway) it immediately tried to unlock wormholes. It also tried to unlock wormholes when I logged back in.

Then, I deleted all of the files and folders I mentioned before and put all of your stuff where Mudlet 3.0 normally installs it - under C:\Program Files (x86) in a self-named folder.

I think the program successfully created the .config and mudlet-data files either way, so it actually doesn't seem to much matter where you run mudlet from, or where all of those lua and dll files are... maybe?

That said, no, this version (also) cannot download a proper map any longer. Sadness.

[JulesK (juleskelworan)]

Ah, okay, so this IS fixable. I am way out of my depth reading this backend script, but I am sure that means "put https instead, or make it look for either http or https there". Thanks.

[Stephen Lyons (slysven)]

Oh dear, that issue in the TLuaInterpreter::downloadFile(...) never got done - and even downloading a IRE map.xml Map File isn't going to help as we haven't inserted any code to load such files manually...

Elevating the priority on this to high...

[Vadim Peretokin (vperetokin)]

This isn't related to downloadFile, as that's not what Mudlet uses to
download the map.

IRE has contacted me today and they might be amenable to restoring the
http:// scheme access. Let's fix the URL used in the source code before the
next snapshot anyway though.

On Tue, Oct 4, 2016 at 7:05 AM Stephen Lyons <email address hidden>
wrote:

> Oh dear, that issue in the TLuaInterpreter::downloadFile(...) never got
> done - and even downloading a IRE map.xml Map File isn't going to help
> as we haven't inserted any code to load such files manually...
>
> Elevating the priority on this to high...
>
> ** Changed in: mudlet
> Importance: Low => High
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1427364
>
> Title:
> 3.0 downloadFile on Windows doesn't support https
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mudlet/+bug/1427364/+subscriptions
>

[Stephen Lyons (slysven)]

The problem that I mentioned on 2015-10-28 which could have caused the original problem whether the right SSL libraries were installed or not has been addressed (and https://bugs.launchpad.net/mudlet/+bug/1366781) in Pull Requests https://github.com/Mudlet/Mudlet/pull/323 (development) and https://github.com/Mudlet/Mudlet/pull/324 (release_30) branches. I believe that the SSL library issues has now been resolved as well.

The issue with regard to I.R.E. XML Map downloads is a separate issue IMHO (but at least with the aforementioned RPs applied you ought to be able to download those map files. It is just that without a manual XML file importer this won't help to solve that issue.) I will try and look at that matter next...

[Vadim Peretokin (vperetokin)]

This has been fixed now.