Hi, I had the same problem, couldn't load http://research.microsoft.com (or any subpage). I tried another browser (arora) and it worked - once. After restarting arora and again trying to load the page it also failed. Same with opera. I tried another iceweasel-profile -> worked. Once.
I looked into the network traffic with wireshark, it looks like this: ## the format: number, system time, source, destination, protocol, info, time 11 01:03:08.075023 192.168.0.155 192.168.0.1 DNS Standard query A research.microsoft.com 4.574382 12 01:03:08.076905 192.168.0.1 192.168.0.155 DNS Standard query response A 131.107.65.14 4.576264 ## so there is no DNS issue involved 13 01:03:08.094167 192.168.0.155 131.107.65.14 TCP 45612 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=9210241 TSER=0 WS=6 4.593526 14 01:03:08.287283 131.107.65.14 192.168.0.155 TCP http > 45612 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1452 4.786642 15 01:03:08.287343 192.168.0.155 131.107.65.14 TCP 45612 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0 4.786702 ## the connection is established correctly 16 01:03:08.287478 192.168.0.155 131.107.65.14 HTTP GET / HTTP/1.1 4.786837 ## with the following content (this is only the actual http-request): GET / HTTP/1.1 Host: research.microsoft.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.9) Gecko/20100501 Iceweasel/3.5.9 (like Firefox/3.5.9) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: s_cc=true; s_sq=msnportalbetarmc%3D%2526pid%253DMicrosoft%252520Research%252520-%252520Turning%252520Ideas%252520into%252520Reality%2526pidt%253D1%2526oid%253Dhttp%25253A//research.microsoft.com/apps/c/1078.aspx%2526ot%253DA ## note that all needed http-keywords and all "\r\n" sequences are present. - this seems to be a valid http request to me. 17 01:03:11.287018 192.168.0.155 131.107.65.14 HTTP [TCP Retransmission] GET / HTTP/1.1 7.786377 ## obviously there was no answer so iceweasel tried again (this is repeated several times until iceweasel gives up). the contents are of course identical to step 16. However, a working request looks like this (only the http-request, first steps are identical): 912 01:13:11.994985 192.168.0.155 131.107.65.14 HTTP GET / HTTP/1.1 608.494344 ## with following content: !N3tEw@@kA`Ph%zP.GET / HTTP/1.1 Host: research.microsoft.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.9) Gecko/20100501 Iceweasel/3.5.9 (like Firefox/3.5.9) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive ## again a valid request, but without a cookie! 913 01:13:12.189427 131.107.65.14 192.168.0.155 HTTP HTTP/1.1 302 Found (text/html) 608.688786 ## this time the connection was accepted and an answer was sent So it seems like http://research.microsoft.com doesn't like cookies. If the cookies are deleted one can once more access the page... I've tried this with iceweasel, arora and Opera on and up-to-date debian squeeze i386 system, with both a WLAN (ipw2200bg) and normal LAN (BCM4401-B0) connections. Can anyone reproduce this behaviour? An easy way to test is to activate iceweasels private browsing mode - when starting the mode no cookies will be available, but they will be temporarily stored until exiting private mode, so you can just start up private mode, visit http://research.microsoft.com/ (should load) and then click some link to another research.microsoft.com page (should not load). Because it happens with all browsers i tested this obviously is no iceweasel bug. However I could not reproduce this bug on a fedora-box at university (running firefox 3.5.9) - even though cookies are saved and also sent (says the live http headers plugin). Is it possible that it is debian-related somehow? I guess if this happened on more systems people would have noticed before.. Cheers, - Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org