Closed Bug 88792 Opened 23 years ago Closed 23 years ago

redirection with no final \r\n not processed

Categories

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

Product:
Core
Component:
Networking: HTTP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: teilo+bugzilla, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: topembed, Whiteboard: r=bbaetz, sr=dougt, verified-on-trunk)

Attachments

(1 file)

v1.0 fixes the problem
911 bytes, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010628
BuildID:    20010628

The above page http://fury.cdt.luth.se:7676/about/ issues an HTTP redirect to a
different page but ommits the final CR-LF pair.

This cause mozilla to show "<html><body></body></html>" in the HTML window



Reproducible: Always
Steps to Reproduce:
1. go to http://fury.cdt.luth.se:7676/about/


Actual Results:  the renderer component displays
<html><body></body></html>

Expected Results:  Either Mozilla (like IE, NS4.08, lynx) asuems the extra CR-LF
is present and supports the redirect or a page explaining the error is displayed.

output from server is:
> telnet fury 7676
Trying 130.240.64.12...
Connected to fury.cdt.luth.se.
Escape character is '^]'.
GET /about HTTP/1.0

HTTP/1.0 302 302
Date: Mon, 02 Jul 2001 13:35:49 GMT
Server: cHTTPd/0.1 Java 1.2fcs/SunOS/5.7/sparc James Nord
Location: http://www.cdt.luth.se/%7Enord/progs/mPing/
Connection closed by foreign host.
confirmed with win95 using 2001070108
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → mozilla1.0
*** Bug 89167 has been marked as a duplicate of this bug. ***
Updating summary. From the dupe, this breaks ford.com.

I can't find anything in the specs to allow this, and the grammar does disallow
it, so I'm 99% sure that its a server bug. I have no idea why we're displaying
text for about:blank - probably something to do with the lack of a content-type
header.

Technically, we have no way of knowing that the server didn't just drop the
connection in the middle, but I suppose we could special case redirections where
the connection drops at the end of a header, if we already have the Location:. I
can't see how this can ever work if the server supports keep-alives, without
waiting for the server to give up and drop teh connection. ns4 manages though...
ccing gagan/dougt for ideas. I'll have to think about this.
Summary: Mozilla gives strange feedback on invalid HTTP responses → redirection with no final \r\n not processed
I agree it's a bug in the server software but the way mozilla handles the error
is IMHO wrong.
Assignee: neeti → gagan
-> gagan to reassign/look into next week
I can not get to the Citibank credit card site where payments are made,
statements are viewed, etc.  http://www.accountonline.com/ (which is redirected
to https://www.accountonline.com/CB/Login.jsp) 

I simply get, <html><body></body></html>, as seems to be the symptom of problems
tied to this bug.

I also can not get to https://login.yahoo.com/

I consider these sites to be top priority for consumers, and they work fine with
IE as well as under some earlier versions of mozilla.
-> darin
Assignee: gagan → darin
This is not a problem on the Solaris 2001073123 build (trunk).  It is still a
problem on the windows 2001073103 build
-> moz0.9.4
Priority: -- → P2
Target Milestone: mozilla1.0 → mozilla0.9.4
not seeing this with my linux 2001-08-01/04 0.9.3 branch build.
i take it back, i am seeing this problem with the original reported link:

http://fury.cdt.luth.se:7676/about/

changing Platform:OS to All:All
OS: Windows NT → All
Hardware: PC → All
Status: NEW → ASSIGNED

    
  
Keywords: patch

    
  
Keywords: topembed

    
    

    
  
This means that we'll never get an error if the server drops the connection
before finishing writing out the headers. This is probably OK, though.

r=bbaetz

    
  
Whiteboard: r=bbaetz, sr=?

    
    

    
  
rs.
Whiteboard: r=bbaetz, sr=? → r=bbaetz, sr=dougt

    
    

    
  
fixed-on-trunk
Whiteboard: r=bbaetz, sr=dougt → r=bbaetz, sr=dougt, fixed-on-trunk

    
    

    
  
As of the Windows 2001080303 trunk build I cannot get to any secure sites. I
enter the URL in the URL bar, the throbber throbs, stops throbbing and nothing
changes.  The previously displayed page is still there. 
http://www.accountonline.com/ -> https://www.accountonline.com/CB/Login.jsp
https://login.yahoo.com/
visa.yahoo.com
etc...

    
  
Target Milestone: mozilla0.9.4 → ---

    
    

    
  
checked original url and Tom's additional urls.  All seem to be working on the
trunk.  Older builds were failing as described.

verified on trunk:
win NT4 2001080804
Linux rh6 2001080810
Mac os9 2001080810

    
    

    
  
qa -> me
QA Contact: benc → tever

    
  
Whiteboard: r=bbaetz, sr=dougt, fixed-on-trunk → r=bbaetz, sr=dougt, verified-on-trunk

    
    

    
  
let's get it on 0.9.2 branch

    
    

    
  
fixed-on-branch
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: