303600 - HTTP 302 redirect ignored

Status: RESOLVED DUPLICATE of bug 221648

(Core :: Networking: HTTP, defect)

Description

[Jerry Baker]

20050803 trunk Firefox

Go to https://www.sce.com/SC3/ContactUs/

That page sends the following headers:
HTTP/1.1 302 Object moved
Server: Microsoft-IIS/5.0
Date: Fri, 05 Aug 2005 17:42:21 GMT
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 157
Location: http://www.sce.com/ContactUs/

You would expect Firefox to follow the redirect. It doesn't. In fact, it does
nothing.

Comment 1

[Frank Wein [:mcsmurf]]

Attachment: NSPR log

Comment 2

[Darin Fisher]

It looks like there was a socket error immediately after reading the 302
response headers.  Notice also that the response carries with it a
Content-Length header that has a non-zero value.  So, it would seem that the
error causes Mozilla to treat the response as erroneous.

Comment 3

[Jerry Baker]

It is interesting to note that the HTTP specification requires HTTP/1.1 user
agents to notify the user when it receives an invalid content-length.

Comment 4

[Marius Strumyla]

If you try http://www.sce.com/SC3/ContactUs/ (NO SSL!) then everything is
working. Firefox redirects you to http://www.sce.com/ContactUs/

Tested with both ff1.0.6 and 20050805 trunk build on Windows 2000.

Comment 5

[Darin Fisher]

IE appears to be more tolerant of broken HTTP servers when it comes to redirect
processing.  I think there's another bug on file somewhere that is similar to
this one.

Comment 6

[Jerry Baker]

The incorrect content-length header is a red herring in light of the fact that
the redirect works HTTP - > HTTP, but fails HTTPS -> HTTP.

Comment 7

[Darin Fisher]

(In reply to comment #6)
> The incorrect content-length header is a red herring in light of the fact that
> the redirect works HTTP - > HTTP, but fails HTTPS -> HTTP.

huh?  the log file indicates a connection failure just after headers are
received.  in other words, the response from the server is bogus.  it is
certainly not valid HTTP/1.1, so anything we do in firefox would be a hack to
workaround this broken server.

Comment 8

[Jerry Baker]

Well, apparently that hack is already in place for HTTP -> HTTP redirects, so
let's just hook up HTTPS redirects to that hack.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

well did you verify that the server behaviour for HTTP is the same? i.e. that it
does not send the data and instead closes the connection

the rest might be duplicate of bug 221648 (or bug 264351)

Comment 10

[Jerry Baker]

The headers are identical. However, it does not appear that the connection is
terminated in the case of HTTP.

Are we sure that this behavior in Firefox is caused by the incorrect
content-length header, and not a networking bug?

Comment 11

[Darin Fisher]

Jerry: Yes.  The read system call is returning an error.  That means that the
connection is dead.  The browser did nothing to cause this error.

*** This bug has been marked as a duplicate of 221648 ***