Bug#541658: problem not only in the network
Pages optimized for IE6 are not necessarily rendered correctly on IE7 or IE8.. so much for Microsofts own standards. Man, you still don't get it. MS changed its standard. Standards do change over time, that's normal. I can help with investigation of wireshark on debian from late July 2010 if you say exactly what to type in. At this very moment unfortunately no debian, only OS X, sorry. Drop me a line then. Ok. It seems to me that it is just hard for most programmers to correctly (with respect to the standards of Cisco MS, in case there is a difference to RFCs) implement some algorithm, which makes the implementation fail in particular networks. The RFCs are the standard, Cisco and MS are not. But Cisco, MS, ... try to comply with these standards, afaik. If they didn't the internet wouldn't work at all. That's wrong. Noone tries to comply with each other, at least not too hard. RFCs describe how the HTTP should work in their opinion. Cisco and MS do the world, using those write-ups as a small notice, but primarily they use their own internal documentation, code and hardware which much better depicts the reality. Who is right, the opus writers or the programmers and hardware builders? The W3C does the HTML-standards Microsoft used to blatantly ignore. It's the other way round. MS does the browser which W3C and the HTML group blatantly ignores. HTML is non-conformant with the most widespread browser, so it's just wrong for the majority of users. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541658: problem not only in the network
On Tue, Jun 29, 2010 at 06:44:18AM -0400, sasha mal wrote: Pages optimized for IE6 are not necessarily rendered correctly on IE7 or IE8.. so much for Microsofts own standards. Man, you still don't get it. MS changed its standard. Standards do change over time, that's normal. I can help with investigation of wireshark on debian from late July 2010 if you say exactly what to type in. At this very moment unfortunately no debian, only OS X, sorry. Drop me a line then. Ok. It seems to me that it is just hard for most programmers to correctly (with respect to the standards of Cisco MS, in case there is a difference to RFCs) implement some algorithm, which makes the implementation fail in particular networks. The RFCs are the standard, Cisco and MS are not. But Cisco, MS, ... try to comply with these standards, afaik. If they didn't the internet wouldn't work at all. That's wrong. Noone tries to comply with each other, at least not too hard. RFCs describe how the HTTP should work in their opinion. Cisco and MS do the world, using those write-ups as a small notice, but primarily they use their own internal documentation, code and hardware which much better depicts the reality. Who is right, the opus writers or the programmers and hardware builders? The W3C does the HTML-standards Microsoft used to blatantly ignore. It's the other way round. MS does the browser which W3C and the HTML group blatantly ignores. HTML is non-conformant with the most widespread browser, so it's just wrong for the majority of users. Will you just stop the pointless babbling and actually help investigate your bug ? Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541658: problem not only in the network
Actually, I've provided all information I could. I'm absolutely not into wireshark or other network tools of whatever kind, but, if you are lazy and unable to do that yourself, well, I might do that, but only starting in late July 2010. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541658: problem not only in the network
But I'll try the MTU hint as soon as I can, thank you for that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541658: problem not only in the network
If you are lazy to reproduce all problems that iceweasel has, close all bugs, not just this one. I've provided as much details as I possibly could. I'm not a wireshark expert to help more. Understand that. The bug has not been fixed. No clear explanation was provided of why the bug occurs. I'll reopen the bug and will keep reopen it until the bug has been fixed, according to the debian guidelines. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541658: problem not only in the network
On Sun, Jun 27, 2010 at 12:51:08PM -0400, sasha mal wrote: It's not their page which is broken. Because they have the majority. The reality is: if a page can be read by the IE, it's a good page. It's the firefox which is broken. The reality is that a lot of pages are written with IE specific stuff that are not part of existing standards, or even worse, written for IE specific bugs or disrespect of the standard. There are even cases where some stupid User Agent sniffing returns an even more broken page if you're not using some browser. That being said, your pages work just fine on iceweasel here, so iceweasel is apparently not at fault here. Again, please make sure everything is fine at the networking level. Ask your network administrator if necessary. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541658: problem not only in the network
There the behavior of IE+Win is, in general, the world standard due to the major market share. Some behaviors (including bugs, no matter how you defined them) of IE+Win don't correspond to that of the other browsers. If some behavior doesn't change in IE+Win for a long period of time (which we observe here), then, yes, that behavior is standard. That being said, your pages work just fine on iceweasel here, so iceweasel is apparently not at fault here. Again, please make sure everything is fine at the networking level. Ask your network administrator if necessary. I do see networks where all browsers opens the pages. But there are also networks where the pages don't get opened in SOME browsers, including firefox. Those networks are absolutely ok in other terms, network administration is with, e.g., the main Spanish telephone company telefonica, which says: use IE. And they are not single networks, or no, I've seen this behavior often in at least three different countries. I remember being told that those pages did't open on firefox even inside MS. Since safari uses partially the netscape code, but lynx uses a different code base, I'm not surprised that the the behavior occurs in safari, but not in lynx. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541658: problem not only in the network
On Mon, Jun 28, 2010 at 10:50:28AM -0400, sasha mal wrote: There the behavior of IE+Win is, in general, the world standard due to the major market share. Some behaviors (including bugs, no matter how you defined them) of IE+Win don't correspond to that of the other browsers. If some behavior doesn't change in IE+Win for a long period of time (which we observe here), then, yes, that behavior is standard. That being said, your pages work just fine on iceweasel here, so iceweasel is apparently not at fault here. Again, please make sure everything is fine at the networking level. Ask your network administrator if necessary. I do see networks where all browsers opens the pages. But there are also networks where the pages don't get opened in SOME browsers, including firefox. Those networks are absolutely ok in other terms, network administration is with, e.g., the main Spanish telephone company telefonica, which says: use IE. And they are not single networks, or no, I've seen this behavior often in at least three different countries. I remember being told that those pages did't open on firefox even inside MS. Since safari uses partially the netscape code, but lynx uses a different code base, I'm not surprised that the the behavior occurs in safari, but not in lynx. Safari doesn't use the netscape code. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541658: problem not only in the network
It does, look into the acknowledgements of Safari: Netscape Communications Corporation ( SpiderMonkey, as used in DateMath.cpp )... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541658: problem not only in the network
On Mon, Jun 28, 2010 at 11:17:33AM -0400, sasha mal wrote: It does, look into the acknowledgements of Safari: Netscape Communications Corporation ( SpiderMonkey, as used in DateMath.cpp )... Yeah, that has anything to do with networking. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541658: problem not only in the network
sasha mal schrieb: There the behavior of IE+Win is, in general, the world standard due to the major market share. Some behaviors (including bugs, no matter how you defined them) of IE+Win don't correspond to that of the other browsers. If some behavior doesn't change in IE+Win for a long period of time (which we observe here), then, yes, that behavior is standard. Repeating this nonsense doesn't make it true. Also, this is not some weird rendering-behaviour (like this crap in IE6-days that caused 80% additional effort in web development just to make a page look ok on IE), but a problem on the network-level. At least http should be implemented sufficiently standard-conform by any browser and webserver. That being said, your pages work just fine on iceweasel here, so iceweasel is apparently not at fault here. Again, please make sure everything is fine at the networking level. Ask your network administrator if necessary. I agree that most probably it isn't Iceweasels fault, because Opera, Chrome, Safari, Arora, even IE6 on my win2k-vbox etc are also affected. IE7 (or IE8) and Firefox on windows server 2008 do load the page - on the same box that fails to load that page under debian. So the problem probably is Linux/Debian specific.. so it may be a valid bug (if it turns out that it's somehow debians fault and not microsofts fault), I hope Mike doesn't mind discussing the bug here until we know the real cause so the bug can be reassigned or closed. I guess I'll have to do further debugging with wireshark etc on both this box and my router to see, if the TCP-Package containing the cookie at least passes my router into the internet and if there really is no answer from research.microsoft.com.. when I find some spare time. I do see networks where all browsers opens the pages. But there are also networks where the pages don't get opened in SOME browsers, including firefox. Those networks are absolutely ok in other terms, network administration is with, e.g., the main Spanish telephone company telefonica, which says: use IE. And they are not single networks, or no, I've seen this behavior often in at least three different countries. I remember being told that those pages did't open on firefox even inside MS. Since safari uses partially the netscape code, but lynx uses a different code base, I'm not surprised that the the behavior occurs in safari, but not in lynx. I'm pretty sure that Safari and Firefox don't share Code that is relevant for this (network-specific) problem. Maybe they share spidermonkey-code, but that is just for JavaScript and has nothing to do with the issue. I'm also quite sure that Opera and Firefox don't share any code. I just tried Lynx Version 2.8.7dev.9 (27 Apr 2008) from debian lenny and it did load the pages.. but didn't use any cookies, even though I enabled them: 2196 491.242293 192.168.0.126 131.107.65.14 HTTP GET /en-us/jobs/default.aspx HTTP/1.0 # note: lynx uses HTTP/1.0 instead of 1.1 # the request: GET /en-us/jobs/default.aspx HTTP/1.0 Host: research.microsoft.com Accept: text/html, text/plain, text/css, text/sgml, */*;q=0.01 Accept-Encoding: gzip, compress, bzip2 Accept-Language: en User-Agent: Lynx/2.8.7dev.9 libwww-FM/2.14 SSL-MM/1.4.1 Referer: http://research.microsoft.com/apps/dp/pe/people.aspx # end see? No cookie. You can try to verify that on your box with wireshark, but I guess it'll look the same and send no cookie, so the page is loaded without problems. How do you connect to the internet with affected boxes? DSL, UMTS, ...? Directly or with a router? What kind of router? etc. Cheers, - Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541658: problem not only in the network
Repeating this nonsense doesn't make it true. You are denying the evident. You have mentioned yourself that a lot of time was invested to support IE. Since the majority of pages supported IE, it just confirms what I'm saying: people try to stick to the standard of IE. In a few cases even crashes and freezes of IE had to be worked around, making those crashes and freezes, well, a standard. The input and testing that you did are great anyway, I appreciate that. I'm pretty sure that Safari and Firefox don't share Code that is relevant for this (network-specific) problem. Maybe they share spidermonkey-code, but that is just for JavaScript and has nothing to do with the issue. lynx is the only browser which ignores JavaScript, so JavaScript handling might be (theoretically, just a guess) one component of the issue. I'm also quite sure that Opera and Firefox don't share any code. You can try to verify that on your box with wireshark, but I guess it'll look the same and send no cookie, so the page is loaded without problems. How do you connect to the internet with affected boxes? DSL, UMTS, ...? Directly or with a router? What kind of router? etc. Currently affected network: Wireless-(unknown)-Spanish telecom. I have very limited access to the (unknown), but I'll try to provide more information. I can help with investigation of wireshark on debian from late July 2010 if you say exactly what to type in. At this very moment unfortunately no debian, only OS X, sorry. It seems to me that it is just hard for most programmers to correctly (with respect to the standards of Cisco MS, in case there is a difference to RFCs) implement some algorithm, which makes the implementation fail in particular networks. Regards Sasha. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541658: problem not only in the network
On Tue, Jun 29, 2010 at 1:39 AM, sasha mal sasha@excite.com wrote: Repeating this nonsense doesn't make it true. You are denying the evident. You have mentioned yourself that a lot of time was invested to support IE. Since the majority of pages supported IE, it just confirms what I'm saying: people try to stick to the standard of IE. In a few cases even crashes and freezes of IE had to be worked around, making those crashes and freezes, well, a standard. Pages optimized for IE6 are not necessarily rendered correctly on IE7 or IE8.. so much for Microsofts own standards. As mentioned before, this really doesn't matter right now, because 1. it's not about rendering but about a simple HTTP GET request (and getting no answer) - as mentioned before, any browser and webserver should at least do this right. 2. it's not it works on IE but not on Iceweasel but it works on windows and not on linux, at least for me (Firefox on Windows *did* work). Until you actually find a system where the page works in IE (even when cookies are sent) but not in Firefox, this is quite certain. The input and testing that you did are great anyway, I appreciate that. I'm pretty sure that Safari and Firefox don't share Code that is relevant for this (network-specific) problem. Maybe they share spidermonkey-code, but that is just for JavaScript and has nothing to do with the issue. lynx is the only browser which ignores JavaScript, so JavaScript handling might be (theoretically, just a guess) one component of the issue. Just do believe me that it has nothing to do with Javascript. Javascript is executed *after* the page was downloaded by the browser - and we're not getting that far. The request for the page is sent, but we don't get any answer. Also, the pages load fine (including javascript, if any), as long as no cookie is sent. I'm also quite sure that Opera and Firefox don't share any code. You can try to verify that on your box with wireshark, but I guess it'll look the same and send no cookie, so the page is loaded without problems. How do you connect to the internet with affected boxes? DSL, UMTS, ...? Directly or with a router? What kind of router? etc. Currently affected network: Wireless-(unknown)-Spanish telecom. I have very limited access to the (unknown), but I'll try to provide more information. I can help with investigation of wireshark on debian from late July 2010 if you say exactly what to type in. At this very moment unfortunately no debian, only OS X, sorry. Drop me a line then. It seems to me that it is just hard for most programmers to correctly (with respect to the standards of Cisco MS, in case there is a difference to RFCs) implement some algorithm, which makes the implementation fail in particular networks. The RFCs are the standard, Cisco and MS are not. But Cisco, MS, ... try to comply with these standards, afaik. If they didn't the internet wouldn't work at all. (Note: The RFCs relevant for this - except for the outdated RFC 1866 - define how the communication is done on the network, not how html-pages are rendered or crap like that so the IE is standard and everyone optimized for IE6 really has nothing to do with that. The W3C does the HTML-standards Microsoft used to blatantly ignore.) Regards Sasha. Cheers, - Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541658: problem not only in the network
Daniel, it's great that you are dealing with that. I've just now tried lynx, firefox, safari on Mac OS X 10.5.8 from the same network. With the result that - lynx 2.8.6rel.5 opens both research.microsoft.com and research.microsoft.com/en-us/people/thoare even when all cookies are accepted, and many more pages from the domain (but, trivially, refuses to open aspx pages), - firefox 3.6.4 refuses to open any pages under research.microsoft.com - safari Version 5.0 (5533.16) refuses to open any pages under research.microsoft.com In my roles as an internet user I don't understand the technical stuff. But I do see that the most popular browser (IE) displays the page. And I do see that it is technically possible for the open browsers like lynx. So, given that Microsoft's IE on Windows is the most popular browser, whether we want it or not, Microsoft defined the standard. Not the HTTP or other specifications. Thus: firefox is defective. Currently, this nonconformant behaviour prevents me from using firefox and makes me use lynx or IE. Not only me. All research folks too. As long as MS doesn't care about how we want them to behave, we have to stick to their standards. Thus: reopening the bug. Sasha. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541658: problem not only in the network
sasha mal schrieb: Daniel, it's great that you are dealing with that. I've just now tried lynx, firefox, safari on Mac OS X 10.5.8 from the same network. With the result that - lynx 2.8.6rel.5 opens both research.microsoft.com and research.microsoft.com/en-us/people/thoare even when all cookies are accepted, and many more pages from the domain (but, trivially, refuses to open aspx pages), - firefox 3.6.4 refuses to open any pages under research.microsoft.com - safari Version 5.0 (5533.16) refuses to open any pages under research.microsoft.com In my roles as an internet user I don't understand the technical stuff. But I do see that the most popular browser (IE) displays the page. And I do see that it is technically possible for the open browsers like lynx. So, given that Microsoft's IE on Windows is the most popular browser, whether we want it or not, Microsoft defined the standard. Not the HTTP or other specifications. Thus: firefox is defective. Currently, this nonconformant behaviour prevents me from using firefox and makes me use lynx or IE. Not only me. All research folks too. As long as MS doesn't care about how we want them to behave, we have to stick to their standards. Thus: reopening the bug. Sasha. Microsoft does not define the standard and just because their page is broken firefox/iceweasel, opera, safari, google chrome, ... don't have to work around it. Even Microsoft themselves seems to have accepted that - since IE7 they produce fairly standard conform browser (compared to the mess of IE6 and before). I tried IE6 on Windows 2000 in VirtualBox and the page didn't load. However: Are we really having the same problem? Does deleting Microsofts cookie fix it for you? (Edit-Preferences-Privacy-remove individual cookies ; then search for microsoft and delete all listed cookies) I also noticed that my mtu-clamping was correct (or should have been at least, if there is no strange bug in the kernel/iptables) before I changed it, but the page didn't load anyway. Also, without any mtu-clamping the page does load.. all this is really strange. # old line (page doesn't load) iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu # new line (page does load) iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu This probably would need deeper investigation (also in the kernel and iptables), but I don't really know where and how to start. Cheers, - Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541658: problem not only in the network
It's not their page which is broken. Because they have the majority. The reality is: if a page can be read by the IE, it's a good page. It's the firefox which is broken. I tried IE6 on Windows 2000 in VirtualBox and the page didn't load. So what? Windows 2000 is not distributed since 2005. Remnants of the support cease in two weeks. IE6 has been shipped with XP and is no more supported. How many users start your dubious configuration of IE6 on Windows 2000 in VirtualBox? Neglectibly few. Does deleting Microsofts cookie fix it for you? (Edit-Preferences-Privacy-remove individual cookies ; then search for microsoft and delete all listed cookies) After deleting cookies the page loads. Every next page doesn't. Removing the cookies make the page loadable again. This probably would need deeper investigation (also in the kernel and iptables), but I don't really know where and how to start. I'm in a position for stating WHAT and HOW things are, but, sorry, I'm not in a position for saying WHY either. Thank you anyway for trying, I really hope it makes a better browser. Regards Sasha. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
