Closed Bug 21055 Opened 20 years ago Closed 20 years ago

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

Categories

(Core :: Networking, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED DUPLICATE of bug 22321

People

(Reporter: tever, Assigned: jud)

References

Details

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
Status: NEW → ASSIGNED
Summary: When using localhost browser attempts to download file → Unknown content-type dialog thrown when HTTP response doesn't contain a content-type
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.
Target Milestone: M13
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.
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
all protocols already do the file ext check (should move outside necko as warren
pointed out).
*** Bug 21241 has been marked as a duplicate of this bug. ***
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 22321 ***
Status: RESOLVED → VERIFIED
Verified dupe of bug 22321
URI dispatcher needs to discern content-type
You need to log in before you can comment on or make changes to this bug.