21055 - Unknown content-type dialog thrown when HTTP response doesn't contain a content-type

Status: VERIFIED DUPLICATE of bug 22321

(Core :: Networking, defect, P3)

Description

[Tom Everingham]

Overview Description:  When using localhost to view http header info
browser attempts a file download.

Steps to Reproduce:
1.)  Run the local java TestServer app
2.)  Launch the browser

Actual Results:  Browser attempts to download a file

Expected Results:  http header should be displayed

Build Date & Platform Bug Found:
1999120708    NT

Comment 1

[Judson Valeski]

changing summary. from "When using localhost browser attempts to download file"

This will happen for any URL that doesn't supply a content-type. We need to
figure out how to deal w/ unknown content-type checking in the front end.

Comment 2

[Warren Harris]

We could try to guess it from the file extension too, if there is one. Maybe
the unknown content type handler should do this instead of necko though.

Comment 3

[rpotts (gone)]

So is this basically the same situation as dealing with the output of a CGI
script that doesn't provide a content-type header?  Or worse a CGI generating
HTTP/0.9 responses?

If it is, then I guess that we need a second level of content-type guessing
based on the stream contents...

It looks like in the old code the following was done:
  - For file: URLs, the contents of the stream was checked to determine if
    content-type was really HTML.  See:
http://lxr.mozilla.org/seamonkey/source/network/protocol/file/mkfile.c#648

  - For http: URLs using HTTP/0.9 the content-type is defaulted to text/html.
See: http://lxr.mozilla.org/seamonkey/source/network/protocol/http/mkhttp.c#2114

  - For http: URLs using any version of HTTP the content-type is defaulted to
text/html.  See:
http://lxr.mozilla.org/seamonkey/source/network/protocol/http/mkhttp.c#2806

So, it looks like in the old code, we only looked at the stream contents for
file:// URLs...  In all other cases we relied on file-extension to MIME-type
mapping or the 'content-type' header from the server...

-- rick

Comment 4

[Judson Valeski]

all protocols already do the file ext check (should move outside necko as warren
pointed out).

Comment 5

[Judson Valeski]

*** Bug 21241 has been marked as a duplicate of this bug. ***

Comment 6

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 7

[Judson Valeski]

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

Comment 8

[Alan S. Jones]

Verified dupe of bug 22321
URI dispatcher needs to discern content-type