199469 - newaol.com - should send .wsz as application/zip (or something)

Status: RESOLVED DUPLICATE of bug 202228

(Tech Evangelism Graveyard :: English US, defect)

Description

[H. Saito]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; pt-BR; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Win98; pt-BR; rv:1.3) Gecko/20030312

its very annoying to user right-click every time.
when i've tried to download files with unusual extensions, they opens as text
file inside the browser, instead of send to download manager. configure helpers
app doesn't work in any circunstances.
this happens with winamp 2 skins(classic - *.wsz), rarlab's winrar file
compressor(*.rar), oggvorbis direct show media(*.ogm), getright download file
list (*.grx), etc



Reproducible: Always

Steps to Reproduce:
1.just put these files in url bar
2.http://ftpwa.newaol.com/customize/component/2003/3/11/S/Akura.wsz
3.http://www.keijin.kit.net/mahou/mahou03.grx
4.http://www.keijin.kit.net/mahou/mahou02.part01.rar

Actual Results:  
 this appear in the browserr
Rar!R•¥¾
ThP-AQ.…R("
+`HP„J 0
=×bùßjQ™¿<ïÏ=þú=Ö½ûsP†fs9ÎnŽ·Ö÷œà~+¿ðšùó®·ÌÎnkS?WiiX	ª	ÿœ32Ú%—;5³3…«’¨¶º”í5€Äµ±p@ŸoV)´øë÷`¯ÿX§÷æîšø¾òãϰ˨Öç÷š®O£@*œ‚âߺ"âן¾Á¾øh»µ¥ÿžê—þ¯{u­Á©
]ɤõµ¯¨¶[ºz¨{ÃDDþd”T“��»¿þUUT“ùÌA]Oy®n­Œg« ~+¡-¡qTœ4hE™¬)ïñ±Ìã-,òÕú)üfö¶æ~PVg=€¾B¿={¢©Ê嬧þE½è/¤±Èü—?I¥udýÙo3„›ÅkreBó¨äÈæÖڄʹðŽÀ¹|m)tQSôÜL-ñ@D9ÿ6*ÜnvœªîŽZCº½þn¼=
Š™ÃFBEHHÚ��­}ª»ƒ>˜Mí?æä¡Q¾î•¨ß}#h^{#“£9ê.†‘ô".€ŽŽ…ö��ÍÞò™´oô




Expected Results:  
download at download manager

Comment 1

[Michael Hendy (Hendikins)]

Reporter: When loading these files, please look at View -> Page Info. If it
lists Type: text/plain, it's a server configuration, in which case this bug
should either be marked as invalid, or moved to Tech Evangelism.

Comment 2

[Zibi Braniecki [:zbraniecki][:gandalf]]

Marking as INVALID. It's not a bug about specific server which could be
evangelized, but about mozilla's proper behaviour.

Comment 3

[H. Saito]

yes, ITS A BUG. but i can download this files at NETSCAPE 4.79 and INTERNET
EXPLORER, independent of server configs..
using mozilla 1.0 and adding helpper-app "application/x-rar-compressed rar" to
winrar files(*.rar) donwload works. in later versions doesn't.

why mozilla is unable to see the difference of plain text file and compresed
archives?

isn't a bug?

Comment 4

[Matthias Versen [:Matti]]

It's no bug !
It's A BUG IN IE that you get a download dialog !
Netscape4.7x also correctly displays this files as text.
The server sends text/plain for this document and Mozilla renders it as text/plain.

>why mozilla is unable to see the difference of plain text file and compresed
>archives?

Because Mozilla must follow the servers choice and the server tells Mozilla that
this is a text file.

example:
wrong server configuration:
http://www.mversen.de/mozilla/text/mozilla.rar

correct server config :
http://www.mversen.de/mozilla/rar/mozilla.rar

Use "right-click-on-link/save link target as" as workaround for the broken server

-> invalid

Comment 5

[H. Saito]

>It's A BUG IN IE that you get a download dialog !

1 - i was talking with a friend and he said that isn't A "BUG IN IE", because as
Windows do, IE prompt - by default - with donwload dialog box for
"unknown/unregistered" files to fix in your own configurations for dummy server
maintainers and let the client users to decide how proceed...

2 - my netscape 4.79 do-it, because he pick the mime-types from windows registry.
in Linux, netscape 4.x can be configured in preferences adding mime-types in
helper applications. i don't know why your netscape 4 doesn't open dialog... if
they use this configurations too.

i don't understand why mozilla doesn't made the same thing, to users decide what
to do?

Mozilla's web browser isn't build to make the users navigation better/easier?

Comment 6

[timeless]

bah. ftpwa.newaol.com is broken.
there are specs which mozilla is required to honor, and it does. that the specs
result in bad things in your opinion doesn't changte the fact that we have to
honor them.

Comment 7

[Matthias Versen [:Matti]]

>i was talking with a friend and he said that isn't A "BUG IN IE"
But this is a bug in IE. IE must also display this link as text-file. It doesn't
do that = bug (it does't follow the RFCs)

>my netscape 4.79 do-it
Do you use a download manager that could break this ?
Your Netscape is broken and my Netscape4.79 (win2k) works as expected.

It doesn't matter if you assign a rar-mimetype in the pref to something because
this link is no rar for the server, it's a text file.

>i don't understand why mozilla doesn't made the same thing, to users decide
>what to do?

Because that would be wrong. There are RFCs about this and a User Agent must use
the mime-type send from the server.

Do you tried the sample URLs from comment #4 ?
a) should display as text and with b) you should get a download dialog

confirming as Tech evangelism for correctiong the mime-type for the newaol
server. Tech Evangelism means = no mozilla bug

Please don't change that unless you read the RFCs.

Comment 8

[H. Saito]

Matti:
i´ve tested and both works in my netscape.
in netscape 6 too. netscape 7 no because i´ve not tested yet. includin the
winamp skins from aol(newaol)... 

and for second time, ISNT A BUG IN IE, BUT AN FILE FILTER.

this information is taken from microsoft developer library(see full content):

http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp

an fragment:

"In Microsoft® Internet Explorer 4.0 and later, MIME type determination occurs
in URL monikers through the FindMimeFromData method. Determining the MIME type
allows URL monikers and other components to find and launch the correct object
server or application to handle the associated content. This section provides a
brief summary of the logic used in determining the MIME type from these sources,
and also discusses some of the issues involved."

"If the "suggested" (server-provided) MIME type is unknown (not known and not
ambiguous), FindMimeFromData immediately returns this MIME type as the final
determination. The reason for this is that new MIME types are continually
emerging, and these MIME types might have formats that are difficult to
distinguish from the set of hard-coded MIME types for which tests exist. A good
example of this is SGML, which can easily be classified incorrectly as HTML
because it contains many of the same tags. Rather than weakening the hard-coded
tests or risk incorrectly classifying new and as-yet-unknown MIME types for
hard-coded known ones, priority is given to the server-supplied MIME type if it
is unknown, since these MIME types are both specific and likely uncommon, and
there are no hard-coded tests that can positively identify them."

Comment 9

[H. Saito]

:second part of message:

microsoft have implemented this filter thinking on the new mime-types that
appears, and for the new files that doesnt mime-types

maybe in mozilla can´t be a bug, but, at least can be an improvment?

isn´t better include some lines to make a filter than make thousands of web
maintaners include new mime-types everytime:

whe i used netscape 4.79 i´ve don´t used download manager(its sucks)..i just put
the mime-type

Comment 10

[Matthias Versen [:Matti]]

>If the "suggested" (server-provided) MIME type is unknown

And the mime-type is not unkown, it's text/plain. IE is broken because the
webmaster told the UA to display text and IE doesn't display it.

open : http://webtools.mozilla.org/web-sniffer/ and add the
http://ftpwa.newaol.com.. link into the form and you will see this header:

HTTP/1.1 200 OKCRLF
Date: Sat, 29 Mar 2003 00:38:46 GMTCRLF
Server: Apache/1.3.26 (Unix)CRLF
Last-Modified: Tue, 11 Mar 2003 20:08:32 GMTCRLF
ETag: "61045-1fa6a-3e6e4240"CRLF
Accept-Ranges: bytesCRLF
Content-Length: 129642CRLF
Connection: closeCRLF
Content-Type: text/plainCRLF
              ^^^^^^^^^^^^ 

It can't be true that the the http://ftpwa.newaol.com link doesn't display text
in NS6, NS7 and NS4.7x (or something is horrible broken on your system). 
You get (of course) a download dialog if you use :
ftp://ftp.newaol.com.. but not with http://ftp.newaol.com..
(a FTP server doesn't send a content-type field and Mozilla use the unkown
content-decoder)

We will not change this (wontfix/invalid) because this would violate the RFC.
Please take discussions about this to the newsgroups or move this bug to
networking:http if you can show us the RFC with something like this : "A UA
should always use the unkown-content sniffer and doesn't follow the sent
content-Type from a Http/1.0 or Http/1.1 server"

The extension ".rar" doesn't count because not all systems are using extension
(mac..) and every http/1.0 or Http/1.1 send a mime-type for each requested URL
for exactly this reason.

>isn´t better include some lines to make a filter than make thousands of web
>maintaners include new mime-types everytime:

they should configure there server to send application/octet-stream for unkown
files. (application/octet-stream= unkown binary file)
That's there job to do that.
And Mozilla already have a unkown-content decoder for Http/0.9 or ftp server
which doesn't send a mime-type in the response header

Comment 11

[H. Saito]

ok. wontfix

Comment 12

[Matthias Versen [:Matti]]

no, this is in the component "tech Evang" for the newaol server.
We will try to mail the webmaster of this server to correct the error.

Comment 13

[Bob Clary [:bc] (inactive)]

tech evang june 2003 reorg

Comment 14

[Bob Clary [:bc] (inactive)]

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