Closed
Bug 83465
Opened 24 years ago
Closed 24 years ago
response with empty content-type opens helper dialog (telocity dsl modem/router)
Categories
(Core :: Networking: HTTP, defect, P1)
Tracking
()
VERIFIED
FIXED
People
(Reporter: erich, Assigned: darin.moz)
References
()
Details
(Keywords: topembed, Whiteboard: r=bbaetz, sr=mscott)
Attachments
(2 files)
|
(deleted),
patch
|
Details | Diff | Splinter Review | |
|
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
|
Reporter | |
Comment 2•24 years ago
|
||
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.
|
||
Updated•24 years ago
|
Summary: response with empty content-type opens helper dialog → response with empty content-type opens helper dialog (telocity dsl modem/router)
|
||
Comment 6•24 years ago
|
||
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...
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
|
Assignee | |
Comment 8•24 years ago
|
||
-> mozilla 0.9.4 (this should be a trivial fix)
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.4
|
|
Assignee | |
Comment 10•24 years ago
|
||
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).
|
|
Assignee | |
Comment 11•24 years ago
|
||
|
||
Comment 12•24 years ago
|
||
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.
|
|
Assignee | |
Comment 13•24 years ago
|
||
|
|
||
Comment 14•24 years ago
|
||
r=bbaetz
|
|
Assignee | |
Updated•24 years ago
|
Whiteboard: r=bbaetz, sr=?
|
||
Comment 15•24 years ago
|
||
sr=mscott
|
|
Assignee | |
Updated•24 years ago
|
Whiteboard: r=bbaetz, sr=? → r=bbaetz, sr=mscott, fixed-on-trunk
|
|
Assignee | |
Updated•24 years ago
|
Target Milestone: mozilla0.9.4 → ---
|
||
Comment 16•24 years ago
|
||
works on trunk:
Win NT 2001080804 (originally failing on win NT also)
Linux rh6 2001080810
Mac os9 2001080810
|
|
||
Updated•24 years ago
|
QA Contact: benc → tever
|
|
||
Updated•24 years ago
|
Whiteboard: r=bbaetz, sr=mscott, fixed-on-trunk → r=bbaetz, sr=mscott, verified-on-trunk
|
|
Reporter | |
Comment 17•24 years ago
|
||
Yay, verified works with a Telocity router. Thanks!
2001081003 win-32
|
||
Comment 18•24 years ago
|
||
*** Bug 94840 has been marked as a duplicate of this bug. ***
|
||
Comment 19•24 years ago
|
||
let's get it into 0.9.2 -- thanks
|
|
Assignee | |
Comment 20•24 years ago
|
||
fixed-on-branch
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
|
||
Comment 21•22 years ago
|
||
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.
Description
•