Closed
Bug 105917
Opened 23 years ago
Closed 22 years ago
Downloading attachments in Hotmail goes into infinite redirect loop
Categories
(Core :: Networking: Cookies, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla1.0
People
(Reporter: greenrd, Assigned: morse)
References
()
Details
(Keywords: top100)
Attachments
(5 files, 2 obsolete files)
85.47 KB,
text/plain
|
Details | |
60.75 KB,
text/plain
|
Details | |
12.64 KB,
text/plain
|
Details | |
1.24 KB,
patch
|
samir_bugzilla
:
review+
alecf
:
superreview+
|
Details | Diff | Splinter Review |
1.70 KB,
patch
|
samir_bugzilla
:
review+
darin.moz
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
If you create a Hotmail account and email yourself an email with an attachment, and then attempt to download that attachment from Hotmail, mozilla gets stuck in an infinite redirect loop. It goes continually in and out of SSL mode. Not sure if this is a mozilla bug or a Hotmail browser detection bug. This has been the case for several weeks now.
Comment 1•23 years ago
|
||
-> File Handling -> Normal
Assignee: asa → law
Severity: critical → normal
Component: Browser-General → File Handling
QA Contact: doronr → sairuh
Comment 2•23 years ago
|
||
I see this as well... you get put into an endless "Please re-enter your password." loop.
Comment 3•23 years ago
|
||
Bill (or whomever takes this bug) is going to need a test account to try this. So, if you have a test Hotmail account, you may wish to e-mail the username/password to Bill (law@netscape.com) or sairuh@netscape.com. Be sure to mention that it's in regard to bug 105917.
Comment 4•23 years ago
|
||
i have set up a test account. I sent email to Bill (law@netscape.com) and sairuh@netscape.com with details.
Comment 5•23 years ago
|
||
No dupes found, but dupes suspected. Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: DUPEME
I fixed a problem with redirects when downloading. Is this one fixed, by any chance? If not, targetting for 0.9.7.
Target Milestone: --- → mozilla0.9.7
Comment 7•23 years ago
|
||
Mozilla not being smart about redirection loops is covered in bug 83471, but maybe there is more to the Hotmail instance.
Comment 8•23 years ago
|
||
Still happens on 2001110803, able to reproduce on win98, 2k, and ME. Marking OS All (was previously Linux).
OS: Linux → All
.
Assignee: law → darin
Component: File Handling → Networking: HTTP
QA Contact: sairuh → tever
Comment 10•23 years ago
|
||
Brian: Now that the bug is assigned to darin@netscape.com (with QA tever@netscape.com), you may wish to send them the details for the test account.
Comment 11•23 years ago
|
||
no need.. i already have a hotmail account with which to test this.
Updated•23 years ago
|
Severity: normal → major
Status: NEW → ASSIGNED
Priority: -- → P2
Updated•23 years ago
|
Whiteboard: DUPEME
Comment 12•23 years ago
|
||
*** Bug 106441 has been marked as a duplicate of this bug. ***
Comment 13•23 years ago
|
||
This seems to be a cookie problem. You can duplicate this behavior in IE 6 by editing its privacy settings to prompt for all cookies. When you go to download the attachment, you are prompted for a session cookie from a 64. site (64.4.32.251), name SafeRedirect, Path /, Data %26hm___ts%3d1007219981%26hm___ha%3df20c35cef4d62928d19f75a2c2ca4b9d If you deny this cookie you get logged out under IE 6. Note I tried this in Konquerer 2.2.1 under Linux as well as Opera 5.10 under Windows and they work, so I don't think Microsoft is pulling anything! Both of those browsers prompt for that cookie. Also, Mozilla does not prompt for the cookie when set to prompt for cookies. I then set Mozilla to accept all cookies and it still doesn't work. Tested with 0.9.6 mozilla under w2k and a nightly linux build, 0.9.6+, 2001112009
Comment 14•23 years ago
|
||
Sigh, ammend above comment to say I tested with Linux nightly 2001112911. I typed in the build number from the wrong window. sorry... Also, after posting, I am now hoping the cookie data doesn't contain enough info to get into my passport. It's a pseudonym with no sensitive data so not all is lost, but I can be a real doofus at times! When entering it my first thought was that no one would be so stupid to put authentication data into a cookie but then after submitting it, I remembered recent history regarding passport... :( I also voted for this bug. IMO a lot of the mainstream public will use hotmail and not having it work with mozilla will just push them to IE.
Reporter | ||
Comment 15•23 years ago
|
||
--> cookies
Assignee: darin → morse
Status: ASSIGNED → NEW
Component: Networking: HTTP → Cookies
Comment 16•23 years ago
|
||
May be the same problem as described in bug 110501, another instance where cookies are not being accepted.
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.7 → mozilla0.9.9
Comment 17•23 years ago
|
||
Adding block: bug 92997, as this bug is the only obstacle to my mom using Mozilla.
Blocks: advocacybugs
Comment 18•23 years ago
|
||
*** Bug 118196 has been marked as a duplicate of this bug. ***
Comment 19•23 years ago
|
||
I've taken a bit of time to capture the http packets for both moz and ie clicking on an attachment's link. I captured using Ethereal, so if someone wants the data in tcpdump format, feel free to email me ( moku_@hotmail.com ) and I'll send it. I'll attach them here as plain text files. I haven't had time to go through and compare the packets side-by-side, so no analysis by me (yet.) I did compare the 2 URLs, and other than the "curmbox" section (which I think is randomly generated each time you log in), the link is indeed identical, so there's nothing funny going on with the link generation done by the server. Hopefully I'll get a chance to look at this within a day or 2, but it's very likely I won't.
Comment 20•23 years ago
|
||
Comment 21•23 years ago
|
||
Comment 22•23 years ago
|
||
Sorry for the bug spam ... didn't think I'd get to this any time soon. This is a humanized & merged version of the previous 2 attachments, plus a few notes. Indeed, as mentioned earlier, the cookie is either not being set or just not being sent to the server. My uneducated guess is that it has something to do with the 302's hotmail uses.
Assignee | ||
Comment 23•23 years ago
|
||
I'm a little confused by the traffic you posted. Let me summarize what I am seeing in your traffic: Step 1: Request for lw2fd.hotmail.msn.com/cgi-bin/saferd Step 2: Response saying it was moved to http://216.32.180.250/cgi-bin/saferd Step 3: Response saying it was moved to http://216.32.180.250/cgi-bin/getmsg Set cookie for 216.32.180.250 and path / Step 4: Request for 216.32.180.250/cgi-bin/getmsg No cookie sent in MOZ case, cookie is sent in IE case So where is the request that caused the second response. The single request in step 1 would not generate two responses.
Comment 24•23 years ago
|
||
As well you should be confused ... I haven't slept in nearly 2 days, and when I edited the two files together, I completely forgot to include the requests for the 2nd 302. They're insignificant (afaict), but I'll add another attachment for clarity. In case I've forgotten or mangled anything else in this new comparison, know that this is just a whittled-down version of the first 2 attachments. If anything is unclear, use those for reference.
Attachment #65836 -
Attachment is obsolete: true
Assignee | ||
Comment 25•23 years ago
|
||
Not going to make it in 0.9.9. Pushing out to 1.0
Target Milestone: mozilla0.9.9 → mozilla1.0
Comment 26•23 years ago
|
||
*** Bug 127021 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 27•23 years ago
|
||
The problem is being caused by the fact that a site at an IP address is setting a domain cookie. That should be illegal -- what does a domain mean in the IP-address context (is 216.32.180.250 in the .32.180 domain)? For that reason, attempts to set such cookies are rejected. That happened when the patch for bug 100682 was checked in (September 20, 2001). So that breaks hotmail! Should we try to evangelize that site? It will probably be futile to even attempt that. So instead I'll loosen the conditions a bit and allow an IP-address site to set a domain cookie providing the domain name and the host name are identical (no checking for tail matches as in done for true domains). Attaching patch that accomplishes this.
Assignee | ||
Comment 28•23 years ago
|
||
Assignee | ||
Comment 29•23 years ago
|
||
cc'ing alecf and sgehani for reviews.
Comment 30•23 years ago
|
||
so, just to clarify, the domainName and the hostName are both equal to the string representation of the ip address right? so if http://1.2.3.4/ tried to set a domain cookie, it would succeed as long as the domain they were attempting was "1.2.3.4"?
Assignee | ||
Comment 31•23 years ago
|
||
That is correct.
Comment 32•23 years ago
|
||
hmm.. probably doesn't play well with virtual hosting, but i guess that shouldn't be a real concern... if a site sets a ip-address-literal cookie, then it should know that virtual hosting isn't going to be an issue, or whatever.
Assignee | ||
Comment 33•23 years ago
|
||
I don't know what "virtual hosting" is. But let me clarify something here. This has nothing to do with an IP site setting a normal (host) cookie. The ip test is made only when an IP site attempts to set a domain cookie. Does that take care of your "virtual hosting" concerns?
Comment 34•23 years ago
|
||
morse: virtual hosting is when a webserver at a particular ip-address acts like several different domains. for example, sawfish.sourceforge.net -> 216.136.171.201 ngrep.sourceforge.net -> 216.136.171.201 these are two different websites, but they are served by the same ip-node. should the first site be able to see cookies from the second? if one sets cookies on 216.136.171.201 then the other would be able to see them right? i'm not sure if this is really a problem since websites shouldn't be setting cookies with numeric domains unless they really mean to.
Comment 35•23 years ago
|
||
Comment on attachment 71009 [details] [diff] [review] allow ip-address sites to set domain cookies if hostName == domainName sounds good to me then! sr=alecf
Attachment #71009 -
Flags: superreview+
Assignee | ||
Comment 36•23 years ago
|
||
darin, ok I understand now. Yes, this is something that the website needs to be careful about if it is playing such games. I have seen bugs resulting where www.google.com and google.com are virtual-hosted in this way. Specifically the google preferences don't work if you enter the site from google.com because the cookies are rejected. It's definitly a site problem and not even an evangelism one (google fails on all browsers -- nav4, mozilla, and IE).
Comment 37•23 years ago
|
||
Comment on attachment 71009 [details] [diff] [review] allow ip-address sites to set domain cookies if hostName == domainName r=sgehani
Attachment #71009 -
Flags: review+
Assignee | ||
Comment 39•23 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 40•23 years ago
|
||
_spam_ This has been the biggest pain in my neck. So I'd just like to say "YAY!" if no one minds :)
Comment 41•22 years ago
|
||
*** Bug 129710 has been marked as a duplicate of this bug. ***
Comment 42•22 years ago
|
||
verified, 03/08/02 trunk - win NT4, mac osX, linux rh6
Status: RESOLVED → VERIFIED
Comment 43•22 years ago
|
||
This still happens on build 2002-03-15-03 with *.eml files on windows 98! I try to open an attachment and instead of file download dialog I get the reenter your password page...
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 44•22 years ago
|
||
Well this was working -- for a fleeting moment. But it looks like the patch in bug 130752 (checked in 3-14-2002) broke this.
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 45•22 years ago
|
||
Comment 46•22 years ago
|
||
Comment on attachment 74809 [details] [diff] [review] Patch to fix regression caused by checking for 130752 BTW: this does not cover IPv6 address literals, e.g. "::10.169.106.21" and this is only a simple example of an IPv6 address literal. PR_StringToNetAddr might be better, since it'll fail if the string is not an IPv4 or IPv6 address literal. actually, it'll fail if the underlying OS doesn't understand the string as an IP address literal.
Attachment #74809 -
Flags: needs-work+
Assignee | ||
Comment 47•22 years ago
|
||
Attachment #74809 -
Attachment is obsolete: true
Comment 48•22 years ago
|
||
Comment on attachment 74824 [details] [diff] [review] using PR_StringToNetAddr instead looks good to me... does it pass all the tests? sr=darin
Attachment #74824 -
Flags: superreview+
Assignee | ||
Comment 49•22 years ago
|
||
Yes it does.
Comment 50•22 years ago
|
||
Comment on attachment 74824 [details] [diff] [review] using PR_StringToNetAddr instead r=sgehani
Attachment #74824 -
Flags: review+
Comment 51•22 years ago
|
||
Comment on attachment 74824 [details] [diff] [review] using PR_StringToNetAddr instead a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #74824 -
Flags: approval+
Assignee | ||
Comment 52•22 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 53•22 years ago
|
||
*** Bug 132625 has been marked as a duplicate of this bug. ***
Comment 54•22 years ago
|
||
verified: 04/09/02 trunk, win NT4, Linux rh6, mac osX
Comment 56•22 years ago
|
||
*** Bug 144278 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•