overwriting data with nullbytes won't work either. If you did it and downloaded the file fine any reasonable person would just say, but you didn't download it fromt he same server. I see where you're going with this, you think that at that portion (actually for me the place it stalls changed) there is some data that when sent in the packet gets caught by the packet manager and causes it to stall, that idea isn't out there, and sounds sorta feasable, but if you know packet shaping software (intelligent firewalls) you will know that rather than creating 256K or more memory space checkign each and every packet sent, which is dumb because the packet manager will end up wasting resources on junk packets that don't help ot do its job, they rather grab and check the packets that are responsible for creatign and maintaining the connection, they look at packet structure as well as type of data sent and of course source port, destination port etc etc. That way they only read packets that help it do its job. So if the stall was due to the packet shaping then it would not create the connection or throttle it all the way through, not stall.
But, we all know WBS isn't above making a hiccup or two, so maybe there is something in that specific packet that gets dropped because of thier shaping rules (but again, why would they drop it and not throttle it, as far as I know WBS don't have policies to BLOCK traffic, just shape it)... but I'm sticking with the cache server thing for now.
Can someone run a packet sniffer when downloading that area of the file and paste the packets for us to see?