Posted October 8, 2020 Hello, When clicking the link for the WurmLauncher.tar.gz on the download page, the browser opens it as a text file instead of downloading it as a file. The problem seems to be that the text server sets the Context-Type header to "text/plain" instead of something more sensible like "application/octet-stream". I also noticed that tar was unable to extract the file directly. Using something like "tar xf WurmLauncher.tar.gz" just resulted in tar: This does not look like a tar archive tar: Skipping to next header tar: Exiting with failure status due to previous errors Even if I specify the compression explicitly by using "xzf", tar was unable to extract the archive. Running gunzip first and then using tar to extract the now uncompressed tarball did work, though. I can't really explain what is going on here, but maybe you know more than I do. This is with GNU tar. 1 Share this post Link to post Share on other sites
Posted October 8, 2020 (edited) I encountered these troubles as well, they seem to be firefox specific. Did you try to download using wget or curl? wget https://client.wurmonline.com/client/wurmlauncher.tar.gz worked fine, the file was ok curl https://client.wurmonline.com/client/wurmlauncher.tar.gz >wurmlauncher.tar.gz works too. Update: Tried with lynx, doesn't work, like in firefox. Opera works. So does konqueror though it throws a few errors on client.wurmonline.com, but download works fine. Edited October 8, 2020 by Ekcin addendum Share this post Link to post Share on other sites
Posted October 9, 2020 Well, the website claims it is text/plain: $ curl --head https://client.wurmonline.com/client/wurmlauncher.tar.gz HTTP/2 200 server: nginx date: Fri, 09 Oct 2020 08:15:06 GMT content-type: text/plain content-length: 3553204 last-modified: Thu, 11 Jul 2019 11:30:25 GMT vary: Accept-Encoding etag: "5d271dd1-3637b4" accept-ranges: bytes So if other browsers properly download the file, they are actually going against what the web server tells them. I did actually download the file with wget and had trouble extracting it. Interestingly, I just tried it again and it worked. I'll assume I did something wrong, then and the file is fine. The Content-Type header needs fixing, though. 1 Share this post Link to post Share on other sites
Posted November 10, 2020 Alright, I'm gonna bump this. I don't understand how this is still not fixed a month later. Guys, your download does not work. Unless you know how to circumvent it, you cannot download the Linux client. And it's such an easy fix. Let me reiterate: The download doesn't work! 1 Share this post Link to post Share on other sites
Posted November 10, 2020 3 hours ago, Xandaros said: Alright, I'm gonna bump this. I don't understand how this is still not fixed a month later. Guys, your download does not work. Unless you know how to circumvent it, you cannot download the Linux client. And it's such an easy fix. Let me reiterate: The download doesn't work! It's just getting bumped to me. I'll have a look. I'm not sure why it would think 'tar.gz' is plain/text. 1 Share this post Link to post Share on other sites
Posted November 11, 2020 The issue should be resolved now. Thank you for reporting this to us. 2 Share this post Link to post Share on other sites
Posted November 11, 2020 It is indeed, though it does require a cache clear, at least in Firefox. In this case, I'm blaming the browser for this behaviour. The header contains the content type and it shouldn't use a cached version over the new one. In any case, you might want to update last-modified and etag to fix it. Or not. I doubt this affects many people, to be honest. Share this post Link to post Share on other sites