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)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: erich, Assigned: darin.moz)

References

(
URL
)

Details

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

Attachments

(2 files)

v1.0 fixes the problem
560 bytes, patch
Details | Diff | Splinter Review
v1.1 better fix
1.74 KB, 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.
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).

    
  
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
        — 
          — 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: