Sign in to follow this  
Xandaros

[Website] WurmLauncher.tar.gz wrong mime type

Recommended Posts

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.

  • Like 1

Share this post


Link to post
Share on other sites

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 by Ekcin
addendum

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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!

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

The issue should be resolved now.

 

Thank you for reporting this to us.

  • Like 2

Share this post


Link to post
Share on other sites

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this