hotmail home page is blank

VERIFIED FIXED

Status

()

Core
Networking
P3
major
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: Rod de Lima-Lopes, Assigned: ruslan)

Tracking

({top100})

Trunk
top100
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+], URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
mozilla does not load webmail pages, sucha as www.hotmail.com all we get is a
blank page

Comment 1

17 years ago
Hrmm.  This seems to be a bad interaction between Mozilla and Microsoft IIS 5.0,
which is not strictly following RFC 2616.  I believe the problem is that Mozilla
is sending a Connection: keep-alive, while IIS is responding with a 302, and
closing the connection but *not* sending Connection: close.  The RFC states:

"If the server chooes to close the connection immediately after sending the
response, it SHOULD send a Connection header including the connection-token close"

Since the specification uses SHOULD instead of MUST, Mozilla should be able to
handle this situation.  4.x handles this fine.

Reassigning to networking.
Assignee: asa → gagan
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking
Ever confirmed: true
Keywords: correctness
QA Contact: doronr → tever
Summary: loading pages → hotmail home page is blank

Comment 2

17 years ago
'correctness' doesn't make sense in this case

nominating for beta3.
Severity: critical → major
Keywords: correctness → nsbeta3, regression, top100
OS: Linux → All
Hardware: PC → All

Comment 3

17 years ago
present in M17 and M18 nightly (10 Aug 2000)

Comment 4

17 years ago
->ruslan
Assignee: gagan → ruslan
Whiteboard: [nsbeta3+]
(Assignee)

Comment 5

17 years ago
Hmm. Looks like hotnail just drops the connection after the first request line 
not even sending a newline after headers. This is bizare ...
Status: NEW → ASSIGNED
(Assignee)

Comment 6

17 years ago
cc: gagan

Updated

17 years ago
Blocks: 48525

Updated

17 years ago
No longer blocks: 48525

Comment 7

17 years ago
*** Bug 48625 has been marked as a duplicate of this bug. ***

Comment 8

17 years ago
Wow IIS is a real piece of junk.  It sends the response and drops the connection
after the very first \n, just like ruslan said.  That is totally against RFC
2616, if my reading is correct.  It seems like the proper handling of this case
is to display an error page.
(Assignee)

Comment 9

17 years ago
What I'm thinking however is putting a kludge which will fire OnHeadersAvailable 
right inside of OnStop if Location header is detected - a bit tricky but it can 
be done. Putting up an error message is tempting, but I don't know if PDT will 
agree with that. BTW - removing regression keyword - it's not out regression, 
but MS's.
Keywords: regression

Comment 10

17 years ago
The reason this worked in 4.x is that we initiated the new redirected request
right after detecting the Location header. (And hence never really waited for
anything else) This is obviously the wrong thing to do in the new world order. I
am proposing a quirk mode option to enable sending OnHeadersAvailable right
after Location header to mimic this behaviour. 

Comment 11

17 years ago
Just to be clear, there are three abnormal behaviors demonstrated by hotmail in
this example:

1) The server is responding after the first newline.  This is against the RFC
2) The server is sending only one CRLF after the response.  Also against the RFC
3) The server is not sending Connection: close, which is recommended by the RFC
(Assignee)

Comment 12

17 years ago
Created attachment 13066 [details] [diff] [review]
The fix
(Assignee)

Comment 13

17 years ago
Proposed fix attached. Awaiting review - Gagan?
(Assignee)

Comment 14

17 years ago
Fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 15

17 years ago
Hotmail homepage now loads on Linux 2000-08-19-08.  All hail IIS 5.0.  sigh.

Comment 16

17 years ago
*** Bug 50253 has been marked as a duplicate of this bug. ***

Comment 17

17 years ago
verified:
WinNT 2000082308
Linux 2000082408
Mac8.6 2000082308
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.