the socket library itself shouldn't wait for protocol specific packets.
only if there is some sort of filtering mechanism on the box for the
http protocol, then it would do it
Filip
Peter Warren wrote:
But this client isn't using a proxy. I've even tried the same client
on my home network,
yes, most proxies will wait until they receive the end of the response,
before passing it on.
that's what you are seeing, a regular servlet, ends the response right away
Filip
Peter Warren wrote:
What is interesting to me is that the exact same client code only
using a different url (i.e. to
Hello,
I've had problems with long http responses and some kind of antiviruses
and internet firewalls (avg family, basically).
They put a hook on the winsocket stack for http connections and buffer
everything you are receiving, until the end (or some high amount of
data), to run the checks.
What is interesting to me is that the exact same client code only
using a different url (i.e. to a normal http servlet, not a comet
servlet) succeeds. Is there something in comet response headers that
an antivirus app or firewall would pick up on? Why would a request to
a normal servlet succeed
I posted this question along with some others recently. I'm
re-posting it in its own thread with some additional information.
I have a comet client app that works on all the machines I've tested
except one. The failing machine sends a comet request to the server
and then waits indefinitely for
