So there might be your answer - I guess "nv" stands for "netvision" - give them the URL and ask them to clear the cache for it.
On 22 March 2015 at 05:56, Michael Tewner <tew...@gmail.com> wrote: > I'm seeing the same thing, that is, the downloaded files start to differ > at byte #4101 > > - The HTTPS version downloaded quite fast on my 5Mbps connection. The > HTTP one is taking forever, quite literally; it's "stalled" > - I've tried adding "Cache-Control: no-cache" and "Pragma: no-cache", > but still getting the alternate file. > > tcptraceroute shows that the HTTP is most probably being cached; First > using HTTP, then using HTTPS: > > MacBook-Air:tmp $ tcptraceroute nodejs.org 80 > Selected device en0, address 192.168.1.107, port 57585 for outgoing packets > Tracing the path to nodejs.org (165.225.133.150) on TCP port 80 (http), > 30 hops max > 1 192.168.1.1 4.144 ms 1.739 ms 1.139 ms > 2 lo10.cab2.hfa.nv.net.il (212.143.205.233) 15.141 ms 12.162 ms > 11.659 ms > 3 core1-cab1-hfa.hfa.nv.net.il (212.143.207.16) 15.204 ms 13.932 ms > 12.857 ms > 4 gw2-0-2-0-1-core1.hfa.nv.net.il (212.143.7.25) 11.599 ms 12.655 ms > 16.048 ms > 5 165.225.133.150 [open] 157.406 ms 157.195 ms 168.028 ms > > MacBook-Air:tmp $ tcptraceroute nodejs.org 443 > Selected device en0, address 192.168.1.107, port 57586 for outgoing packets > Tracing the path to nodejs.org (165.225.133.150) on TCP port 443 (https), > 30 hops max > 1 192.168.1.1 3.398 ms 1.755 ms 1.230 ms > 2 lo10.cab2.hfa.nv.net.il (212.143.205.233) 11.704 ms 16.318 ms > 11.138 ms > 3 core1-cab1-hfa.hfa.nv.net.il (212.143.207.16) 14.981 ms 13.580 ms > 17.064 ms > 4 gw2-0-3-0-0-core1.hfa.nv.net.il (212.143.7.53) 12.450 ms 14.393 ms > 10.653 ms > 5 10.10.40.1 12.454 ms 18.778 ms 14.951 ms > 6 gw2-fra-0-3-0-3-200-gw2.hfa.nv.net.il (212.143.12.12) 67.772 ms > 68.099 ms 110.025 ms > 7 10.10.70.1 70.582 ms 76.711 ms 66.120 ms > 8 xe-4-3-2-302.fra23.ip4.gtt.net (77.67.94.5) 67.824 ms 66.694 ms > 97.753 ms > 9 xe-1-2-3.was14.ip4.gtt.net (89.149.180.198) 154.917 ms 167.244 ms > 168.940 ms > 10 internap-gw.ip4.gtt.net (77.67.69.254) 164.903 ms 175.436 ms > 158.257 ms > 11 border10.pc2-bbnet2.wdc002.pnap.net (216.52.127.73) 156.724 ms > 153.793 ms 164.227 ms > 12 joyent-3.border10.wdc002.pnap.net (64.94.31.202) 166.082 ms 163.434 > ms 163.415 ms > 13 165.225.143.105 163.860 ms 169.177 ms 154.384 ms > 14 165.225.143.15 178.280 ms 152.575 ms 159.958 ms > 15 165.225.133.150 [open] 157.337 ms 162.811 ms 164.262 ms > > > > On Sat, Mar 21, 2015 at 7:48 PM, E.S. Rosenberg <esr+linux...@g.jct.ac.il> > wrote: > >> Depending on the version of windows and it's network environment you >> freshly installed rootkits could be likely, but that is OT here. >> >> Note that different ISP in Israel is a fairly relative statement since >> there are basically just a few major players who own a bunch of the smaller >> ISPs and could have caching proxies on their international lines... >> >> Did you traceroute the connection both from working and non-working >> settings? >> >> Regards, >> Eliyahu - אליהו >> >> 2015-03-21 8:30 GMT+02:00 Amos Shapira <amos.shap...@gmail.com>: >> >>> Just speculating, but could it be that your ISP uses a caching >>> transparent proxy (which would explain why it doesn't happen on SSL) and >>> its cache got corrupted? >>> The "other ISP" case could be explained if it's actually >>> upstream/downstream from your ISP, or they share a proxy cache for other >>> reasons. >>> >>> >>> On 21 March 2015 at 04:07, Roman Ovseitsev <rom...@gmail.com> wrote: >>> >>>> Please forgive the slight off-topic, but I am experiencing a rather >>>> strange issue while downloading a certain file over HTTP. >>>> >>>> Instead of getting node.js installer as expected from here >>>> http://nodejs.org/dist/v0.12.0/node-v0.12.0-x86.msi I am receiving a >>>> completely different executable - an installer for Elcomsoft's Advanced EFS >>>> Password Recovery whatever that is. >>>> >>>> Both files are exactly the same size but SHA sums obviously don't match. >>>> >>>> SSL version of the link - >>>> https://nodejs.org/dist/v0.12.0/node-v0.12.0-x86.msi works as >>>> expected. i.e. downloads the correct node.js installer. >>>> >>>> >>>> I have verified this on three different machines running Fedora, >>>> CentOS, and Windows. None of these machines ever exchanged any files or >>>> used anything else but the default repos. In fact the windows machine is a >>>> 13 years old pc with a freshly installed OS. So presumably that dismisses >>>> any possibility of rootkits. >>>> >>>> It doesn't seems to be due to my router or ISP either. I am getting the >>>> wrong executable on two of my neighbours' Wi-Fi networks and at least one >>>> of them seems to be using a different ISP. >>>> However it doesn't happen on another Israeli nor a couple of US and UK >>>> servers I've tried so far. >>>> I am not using any proxies either. >>>> >>>> nodejs.org domain on all of the above resolves to the same IP. >>>> >>>> >>>> What's going on? >>>> Could be that the ISPs are the culprit? >>>> >>>> Considering that the application is relatively popular and I am the >>>> only one experiencing this issue it doesn't seem to be the case of >>>> nodejs.org server doing this on purpose (knowingly or not). >>>> >>>> _______________________________________________ >>>> Linux-il mailing list >>>> Linux-il@cs.huji.ac.il >>>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il >>>> >>>> >>> >>> >>> -- >>> <http://au.linkedin.com/in/gliderflyer> >>> >>> _______________________________________________ >>> Linux-il mailing list >>> Linux-il@cs.huji.ac.il >>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il >>> >>> >> >> _______________________________________________ >> Linux-il mailing list >> Linux-il@cs.huji.ac.il >> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il >> >> > -- <http://au.linkedin.com/in/gliderflyer>
_______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
