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

Reply via email to