214185 - brinkster.com - serving HTML as application/octet-stream

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect, P3)

Description

[Robert Chan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

I am unable to load an html file that does not have an extension; instead, it
does not know what to do and I have to reselect Mozilla as the program I should
use to open it.

However, it then opens the file from a location on my hard drive - and I am
unable to click on the any of the links because they point to another local
file, which has not yet been downloaded on my hard drive.

Reproducible: Always

Steps to Reproduce:
1. I enter the URL of an html file without an extension
2. I choose to open the file with the default application (Mozilla)
3. The page displays
4. I try to click on the other links
Actual Results:  
It cannot go further, as the local paths lead to files that are not yet existent
on my hard drive.

Expected Results:  
It should have automatically opened the non-extension file from the Internet
instead of manually opening it from the hard drive.

Comment 1

[Glenn Morse]

Attachment: Sample HTMl file without an extension

Comment 2

[Glenn Morse]

I'm not exactly sure what you mean by this bug. If I understand you correctly,
you are opening a HTML file without an extension (from Windows file manager, or
by double-clicking), then selecting Mozilla as the application to open the file
with, which results in the links in the HTML file being corrupted and leading to
incorrect locations, correct? I don't see how you would open a file with Mozilla
and get the program selection dialog from Windows, as Mozilla just opens HTML
files without an extension as raw text. 

I tested this quick with the sample file above, and it works as expected. Can
you supply a page to which this does not work, and more details on the process
that leads to the bug?

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030727

Comment 3

[Robert Chan]

example link:

http://www24.brinkster.com/tusultusest/eastclusterblogroll

its someone's personal brinkster site, and i thought my explanation would make
sense so everyone wouldnt kill the bandwidth

Comment 4

[Robert Chan]

Internet Explorer opens that page above fine

Comment 5

[Bill Mason]

That's because they are serving that page as application/octet-stream, which
basically means 'prompt the browser for what to do with this file'.  So Mozilla
does what the server said to do.

It works in IE because IE always ignores server MIME type settings, a major bug
it has.

The fix is for the site to fix their server.  You might write to them and
suggest it.

->Tech Evangelism

Comment 6

[Michael Baffoni]

I am seeing this at other sites (specifically
http://policyworks.gov/org/main/mt/homepage/mtt/perdiem/travel.shtml - this is
an important government site!).  I've submitted an issue into their system, but
shouldn't we have a quirks mode to ignore application/octet-stream (I don't know
what it's use is outside of these obnoxious problem sites), or perhaps better an
option in the popup dialog box to either ignore MIME type or maybe better an
option to use Mozilla from the native source (rather than from downloaded file
in the temp folder because working from the tempfolder breaks relative links).

Or would you prefer I write that up as an enhancement bug?

Comment 7

[Greg Hammett]

I ran into this same problem independently with the web page

http://policyworks.gov/org/main/mt/homepage/mtt/perdiem/travel.shtml

Microsoft IE shows this web page fine, but Mozilla 1.5 refuses to show the page
because the header sent by the server says it is application/octet-stream:

wget -S http://www.policyworks.gov/org/main/mt/homepage/mtt/perdiem/travel.shtml
--21:15:29-- 
http://www.policyworks.gov/org/main/mt/homepage/mtt/perdiem/travel.shtml
           => `travel.shtml'
Resolving www.policyworks.gov... done.
Connecting to www.policyworks.gov[159.142.132.138]:80... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 200 OK
 2 Server: Microsoft-IIS/4.0
 3 Connection: keep-alive
 4 Date: Thu, 15 Jan 2004 02:15:34 GMT
 5 Content-Type: application/octet-stream
etc...

Though this might officially be a bug in a standards-violating web server, end
users are unlikely to be able to get every web page with such a problem fixed,
particularly if M$ IE displays the page properly because M$ IE ignores the
standard.  One wonders if M$ intentionally puts incompatibilities in their
software like this, so that IT bureaucrats can say "it must be a problem with
free software, because it works okay in my Internet Explorer, so I recommend you
switch to M$ IE".  So it would be nice if there was an option to override the
application/octet-stream header and treat it as html if that is the file's
extension.

Comment 8

[Ross Shannon]

Attachment: login page for Yahoo Mail being sent as octet stream

This is also happening at Yahoo Mail on a successful login.

Comment 9

[M.Paugh]

Additionally, any server which does a 301 or 302 redirect in this way will not work in Firefox.  See for more information:

http://support.microsoft.com/kb/319073

Comment 10

[Matthias Versen [:Matti]]

404