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