.zip files and .rar files?

[fj]

Hi,

Can anybody tell me why I can link to .zip files on my website but not to
..rar files? And how can I link to .rar files?

Thanks, flip

 

[Ed Seedhouse]

Hi,

Can anybody tell me why I can link to .zip files on my website but not to
.rar files? And how can I link to .rar files?

You can link to any file you want. The browser can't display it
however, unless it knows about the files type and what application to
call up for the purpose. Most people don't have .rar viewers so they
won't be able to do anything with the link except download it.

 

[fj]

Hi,

I also tried to link to .exe files but it will not download those files
either. I've downloaded .exe and .rar files from other sites. The .rar files
just show as garbled computer language (I think).

flip

 

[Andy Dingley]

I also tried to link to .exe files but it will not download those files
either. I've downloaded .exe and .rar files from other sites. The .rar files
just show as garbled computer language (I think).

Then it has linked to the file, but not managed to serve it correctly.

As a guess (as a I don't know which site you're talking about) then the
page linking to these files is correct. The server where these files
are located is incorrect and badly configured.

Many servers assume that all the files on them are either "HTML" or
"plaintext", unless they're specific sorts of file (like JPG) that it
knows about. The "type" of files can be guessed from the file extension
in their name, but that's not how the web protocols work. Instead they
have a particular header of "content-type" such as "text/plain",
"text/html", "image/jpeg" or "application/octet-stream".
"application/octet-stream" means "We have no idea what this is, just
treat it as raw data and store it, but don't try to view it, run it or
do anything clever with it"

A well-run server should serve file types that it understands
correctly. It will also need a fallback or default for those it doesn't
understand, and that should be "application/octet-stream". If the
server admins want an easy life and no support calls from people
inventing crazy new file extensions, then the temptation is to set the
default up as "text/plain" (or even worse, "text/html") and then let it
serve everything unknown as if it's a viewable text document.

It looks like the server here understands ZIP files and serves them
correctly, but it doesn't know about RAR files and so lets them default
to text/plain. Your browser then sees this (as instructed) as a
viewable text file and tries to view it.

If you have to link to such a file and download it, then one quick hack
is to find a link to it, then instead of following that link and trying
to save it, instead don't follow the link but just use your browser's
"Save link as..." feature (try the right-mouse menu).

 

[fj]

Thanks,

flip

Then it has linked to the file, but not managed to serve it correctly.

As a guess (as a I don't know which site you're talking about) then the
page linking to these files is correct. The server where these files
are located is incorrect and badly configured.

Many servers assume that all the files on them are either "HTML" or
"plaintext", unless they're specific sorts of file (like JPG) that it
knows about. The "type" of files can be guessed from the file extension
in their name, but that's not how the web protocols work. Instead they
have a particular header of "content-type" such as "text/plain",
"text/html", "image/jpeg" or "application/octet-stream".
"application/octet-stream" means "We have no idea what this is, just
treat it as raw data and store it, but don't try to view it, run it or
do anything clever with it"

A well-run server should serve file types that it understands
correctly. It will also need a fallback or default for those it doesn't
understand, and that should be "application/octet-stream". If the
server admins want an easy life and no support calls from people
inventing crazy new file extensions, then the temptation is to set the
default up as "text/plain" (or even worse, "text/html") and then let it
serve everything unknown as if it's a viewable text document.

It looks like the server here understands ZIP files and serves them
correctly, but it doesn't know about RAR files and so lets them default
to text/plain. Your browser then sees this (as instructed) as a
viewable text file and tries to view it.

If you have to link to such a file and download it, then one quick hack
is to find a link to it, then instead of following that link and trying
to save it, instead don't follow the link but just use your browser's
"Save link as..." feature (try the right-mouse menu).

 

[Jonathan N. Little]

Then it has linked to the file, but not managed to serve it correctly.

As a guess (as a I don't know which site you're talking about) then the
page linking to these files is correct. The server where these files
are located is incorrect and badly configured.

Many servers assume that all the files on them are either "HTML" or
"plaintext", unless they're specific sorts of file (like JPG) that it
knows about. The "type" of files can be guessed from the file extension
in their name, but that's not how the web protocols work. Instead they
have a particular header of "content-type" such as "text/plain",
"text/html", "image/jpeg" or "application/octet-stream".
"application/octet-stream" means "We have no idea what this is, just
treat it as raw data and store it, but don't try to view it, run it or
do anything clever with it"

Aside of adding the mime type via an .htaccess file could he not simply
add the TYPE attribute to his link?

<a href="someRarFile.rar" type="application/x-rar-compressed">The RAR
File</a>

 

[Andy Dingley]

Aside of adding the mime type via an .htaccess file could he not simply
add the TYPE attribute to his link?

<a href="someRarFile.rar" type="application/x-rar-compressed">The RAR
File</a>

This rather depends on how much you admin. If you control the link page
but not the storage, then this is indeed a useful approach.

If you control the server that serves the actual content though, you
should fix it up (maybe through .htaccess) so that the content is
served correctly, no matter how the user gets to that URL or which link
(if any) they followed.

 

[Jonathan N. Little]

If you control the server that serves the actual content though, you
should fix it up (maybe through .htaccess) so that the content is
served correctly, no matter how the user gets to that URL or which link
(if any) they followed.

I offered this because some to not have access to .htaccess.

 

[Toby Inkster]

<a href="someRarFile.rar" type="application/x-rar-compressed">The RAR
File</a>

Correct me if I'm wrong, but isn't this considered "advisory" -- i.e. once
the link has been followed, the real HTTP header over-rides it?

 

[Jonathan N. Little]

Correct me if I'm wrong, but isn't this considered "advisory" -- i.e. once
the link has been followed, the real HTTP header over-rides it?

Not sure, have to do further research, however it does seem to work in
tests....

 

[Jonathan N. Little]

Correct me if I'm wrong, but isn't this considered "advisory" -- i.e. once
the link has been followed, the real HTTP header over-rides it?

Nope I was wrong, I did some further testing and yes you have to set the
HTTP header that the server sends.

The OP would either have to contact his sysadmin hand have them add the
MIME for RAR or if he is allowed to add it himself via the .htaccess