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

Status: RESOLVED WORKSFORME

(Core Graveyard :: File Handling, defect)

Description

[Martin Kutschker]

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.

Comment 1

[Alfonso Martinez]

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

Comment 2

[Arnoud Berendsen]

v

Comment 3

[Martin Kutschker]

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.

Comment 4

[Matthias Versen [:Matti]]

-> File Handling

Comment 5

[Boris Zbarsky [:bzbarsky]]

Martin, it sounds like you have the application/octet-stream type mapped to the
.html extension in your helper app preferences....

Comment 6

[Martin Kutschker]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Looking at this again, I'm willing to bet the server only sends the right type
for GET requests, not for HEAD requests....

Comment 8

[Martin Kutschker]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Martin Kutschker]

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

[Martin Kutschker]

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

[Gábor Lipták]

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

Comment 13

[Dave Sparks]

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.

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

[Ewan Davis]

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

Comment 16

[Martijn Wargers (dead)]

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.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Marking worksforme, in the aftermath of bug 160454