Bug#541658: I can kind of confirm this bug

[Daniel Gibson]

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