'save link target as' treats (all) links incorrectly as html (suggesting .html as extension)



Core Graveyard
File Handling
16 years ago
2 years ago


(Reporter: Martin Kutschker, Assigned: Bill Law)


Windows 98

Firefox Tracking Flags

(Not tracked)




16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
BuildID:    2002053012

In a webmailer (www.blackbox.net) I use, attachments to mails are linked like
this (without extension):

<a href="/cgi-bin/auth/1017330243/att/8001273/Attachement1?att=1">Attachement1</a>

or this (whith extension):

<a href="/cgi-bin/auth/1017330243/att/7965968/richtig.tiff?att=1">richtig.tiff</a>

Mozilla treats the links confusingly as HTML files when trying to use 'save link
target as'.

Reproducible: Always
Steps to Reproduce:
1. choose 'save link target as' on a link like the examples above

Actual Results:
Suggested name: Attachment1 [details] [diff].html
Type: Web Page, HTML only


Suggested name: richtig.tiff.html
Type: Web Page, HTML only

Expected Results:
Suggested name: Attachment1 [details] [diff]
Type: Application


Suggested name: richtig.tiff
Type: Image
Type: Application

Instead of 'Application' perhaps use 'Application Data'.

And on Linux it seems that choosing 'save target', but not saving the file
actually, sometimes disables the link itself.


16 years ago
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 1

16 years ago

*** This bug has been marked as a duplicate of 120327 ***

Comment 2

16 years ago

Comment 3

16 years ago
I am reopening this bug because bug #120327 is now fixed and this bug is NOT. In
Mozilla 1.2beta I still get an .html extension apllied to nearly all links when
clicking SAVE LINK AS (not save pase as). Changing the subject a bit to make it

So for every f** word file I try to download via a webmailer I have to correct
the name.

Perhaps this bug is related to #147679, #160454, #164816 and other. IMHO all
these bugs revolve about Linux issues (tar.gz stuff). Maybe they are fixed. This
bug is not.

This is very annoying and has been an issue for a very long time. Would be great
to have it in 1.2.
Resolution: DUPLICATE → ---
Summary: 'save link target as' treats link incorrectly as html → 'save link target as' treats (all) links incorrectly as html (suggesting .html as extension)
-> File Handling
Assignee: Matti → law
Component: Browser-General → File Handling
QA Contact: imajes-qa → petersen
Martin, it sounds like you have the application/octet-stream type mapped to the
.html extension in your helper app preferences....

Comment 6

16 years ago
No. Though application/octet-stream with the EXTENSION .doc is associated with

It just does not matter wether there is an extension or not. AFAIK the server
sends (more or less) correct mime types.

Now tested with 1.2b, will try 1.2.1 and 1.3a later.
Looking at this again, I'm willing to bet the server only sends the right type
for GET requests, not for HEAD requests....
Whiteboard: DUPEME

Comment 8

16 years ago
This could be the case as the link is being served by a CGI (run by Apache).

OT: Is there a way for a CGI-author to handle HEAD requests? In this particular
case I can do something about it (change server config or CGI). If not Mozilla
will forever mess up extensions on many 'download' URLs.
> Is there a way for a CGI-author to handle HEAD requests?

No idea....  If you find one, please tell me; I have not located one yet.  :(

> If not Mozilla will forever mess up extensions

See bug 160454.
Depends on: 160454

Comment 10

16 years ago
I have investigted this. The CGI sets the correct MIME type for HEAD as well. In
fact it just runs as normal, wihch means it delivers the content, not just the
headers (this can be arbitrary content like JPEGs, TIIFs, Word docs, ..).
Perhaps this is confusing to Mozilla.

Anyway, I don't think that many CGI authors are bothering to deal with a HEAD
request correctly.

Comment 11

16 years ago
I have fixed this CGI to cope with HEAD requests. Now everything works nicely.

It seems that Mozilla gets confused by the extra output of the CGI. Tough it was
the CGI that was buggy, it would be nice if Mozilla could handle such problems

As for CGIs, HEAD requests and Apache: mod_cgi runs the requests for 1.3 and
2.0. It's up to the CGI author to deal with it.

Comment 12

16 years ago
I'm seeing .html .jsp appended to .exe .pdf files downloaded with 2003011604

Comment 13

16 years ago
In my case, the server's sending a '302 Moved Temporarily' response to the HEAD
request, with an HTML body ...

What's particularly annoying is that the link is marked
type="application/octet-stream" because although the target is a PNG image it is
much too large for display - it's a 600 DPI image intended for downloading and
printing.  I'd hoped the type= would stop browsers attempting to display the
image, but I haven't yet found a browser that takes any notice.
Dave, the "type" attribute of <a> is advisory only.  The HTML spec explicitly
says that the server-provided type, if any, overrides it (now if you have a
"type" on a link to a file:// url that's a different story).

Comment 15

14 years ago
using "save link as" via right click in Win XP Pro on link to

I get "The link could not be saved. The web page ...."

double clicking on the link loads the document normally

Running: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913
With the link provided in comment 15:
I can see the bug in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041007
But I can't see the bug in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041018

I think that has been fixed by the fix for bug 160454.
Probably the original bug could also be fixed by the fix for bug 160454, but
afaics, there is no way to test that for me.
Marking worksforme, in the aftermath of bug 160454
Last Resolved: 16 years ago14 years ago
Resolution: --- → WORKSFORME


5 years ago
Whiteboard: DUPEME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.