Hi, On Tue, Jun 14, 2011 at 22:28, Guillaume <[email protected]> wrote: > Thanks for your answer. > I wasn't aware of that an intermediary can buffer data, in fact I don't know > a lot about networks. > In fact, the application I work already on use an implementation of comet > long polling. The connection can remains active for hours and this surprise > because I thought that networks equipment could close an HTTP connection > that lives too long. Someone told me that because it was HTTPS, no equipment > try to cut the connection because it can knows what was doing the > connection. > Do you think this explanation is correct (I try to have different sounding) > ? Can it prevent intermediary to buffer the response too ?
Perhaps the timeouts are different for http and https (which could fall back to the tcp timeout). Intermediaries cannot inspect https content, but some buffering may happen also at the tcp level. If you are on a comet long poll based on http, it's probably the most reliable way (with respect to streaming), but IMHO seems a pity that you're rewriting a solution that already exists. Simon -- http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz _______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
