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

RESOLVED WORKSFORME

Status

Core Graveyard
File Handling
RESOLVED WORKSFORME
16 years ago
2 years ago

People

(Reporter: Martin Kutschker, Assigned: Bill Law)

Tracking

Trunk
x86
Windows 98

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

and

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


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

and

Suggested name: richtig.tiff
Type: Image
or
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.

Updated

16 years ago
Status: UNCONFIRMED → RESOLVED
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
v
Status: RESOLVED → VERIFIED
(Reporter)

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
clear.

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.
Status: VERIFIED → UNCONFIRMED
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....
(Reporter)

Comment 6

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

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
(Reporter)

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
(Reporter)

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.
(Reporter)

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
gracefully.

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
http://www.dh.gov.uk/assetRoot/04/06/75/10/04067510.pdf

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
Firefox/0.10
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
Status: NEW → RESOLVED
Last Resolved: 16 years ago14 years ago
Resolution: --- → WORKSFORME

Updated

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.