Closed Bug 83465 Opened 23 years ago Closed 23 years ago

response with empty content-type opens helper dialog (telocity dsl modem/router)

Categories

(Core :: Networking: HTTP, defect, P1)

x86
Windows 2000
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: erich, Assigned: darin.moz)

References

()

Details

(Keywords: topembed, Whiteboard: r=bbaetz, sr=mscott)

Attachments

(2 files)

If I try to view the built-in web site on the Telocity DSL router, the response looks like ... HTTP/1.0 200 OK Connection: close Server: Gateway WindWeb/1.1 Date: THU JAN 01 08:56:26 1970 Content-Type: WWW-Authenticate: Basic realm="Gateway" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <title>Telocity Services and Status</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> (....) Instead of displaying the HTML, Mozilla opens a helper dialog that says, Downloading null You have chosen to download a file of type: "#1" [#2] from #3 What should Mozilla do with this file? This is related to bug 22321 and bug 65550, with the difference being no content-type vs. empty content-type headers. Admittedly this thing is broken, but Lynx and IE5 render and display the HTML.
Probably not legal, do we want to support this? If not, lets move to evangelism.
For what it's worth I have also tried Netscape 4.77, and it recognizes the HTML just fine. So Mozilla is the only browser I've tried that doesn't... Since the code for autodetecting text/html is already there from bug 22321, Mozilla just needs to ignore the content-type header with no value. Then even if it couldn't figure out the content type, at least the helper dialog would display correctly instead of having the #1 #2 and #3.
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: response with empty content-type opens helper dialog → response with empty content-type opens helper dialog (telocity dsl modem/router)
*** Bug 89947 has been marked as a duplicate of this bug. ***
*** Bug 91451 has been marked as a duplicate of this bug. ***
gagan, this sounds like the bug you are working on... if http-equiv content type tags are honored, this bug should be fixed. This is probably a bigger issue than 90288, but marking as depend anywayz...
Assignee: neeti → gagan
Depends on: 90288
Target Milestone: --- → mozilla1.0
I don't think this is related to HTTP-EQUIV issue. We just need to make sure that our content-type guessing logic kicks in for weird cases like this. cc'ing mscott for his info.
Assignee: gagan → darin
No longer depends on: 90288
-> mozilla 0.9.4 (this should be a trivial fix)
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.4
*** Bug 92553 has been marked as a duplicate of this bug. ***
i've added a simplified testcase at http://g.mcom.com/~darin/bin/83465.cgi (sorry, this link is only valid inside the netscape firewall).
Attached patch v1.0 fixes the problem (deleted) — Splinter Review
Keywords: patch
Priority: -- → P1
Keywords: topembed
Why not just do: if (!*type) return NS_OK; after the LOG? The code in ParseHeaderLine should take care of Content-type:<space><space><space> you've also missed the comment above that routine to change nsMixedMultiModeConv.cpp as well.
Attached patch v1.1 better fix (deleted) — Splinter Review
r=bbaetz
Whiteboard: r=bbaetz, sr=?
sr=mscott
Whiteboard: r=bbaetz, sr=? → r=bbaetz, sr=mscott, fixed-on-trunk
Target Milestone: mozilla0.9.4 → ---
works on trunk: Win NT 2001080804 (originally failing on win NT also) Linux rh6 2001080810 Mac os9 2001080810
QA Contact: benc → tever
Whiteboard: r=bbaetz, sr=mscott, fixed-on-trunk → r=bbaetz, sr=mscott, verified-on-trunk
Yay, verified works with a Telocity router. Thanks! 2001081003 win-32
*** Bug 94840 has been marked as a duplicate of this bug. ***
let's get it into 0.9.2 -- thanks
fixed-on-branch
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
VERIFIED, per reporter. Verified holds trunk status. I don't even know if anyone cares about 0.9.2 branch verifications anymore...
Status: RESOLVED → VERIFIED
Component: Networking → Networking: HTTP
Whiteboard: r=bbaetz, sr=mscott, verified-on-trunk → r=bbaetz, sr=mscott
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: