v2nek/webchat2

Not a defect. Question regarding buffering proxies.

Opened this issue · 0 comments

What steps will reproduce the problem?
1. Access the webchat interface when behind a buffering proxy (client side).
2.
3.

What is the expected output? What do you see instead?
Expected output is the <script>'s to be returned to the browser.

What actually happens is that the proxy buffers the response (since there
is no content-length) and presumably will continue to buffer until the
connection is closed or a timeout has been reached.

I have tried chunked encoding with each script being returned as a chunk. 
This is still buffered.  I have also tried padding the responses with lots
of whitespace to trip the buffer.  While the buffer trips and the response
is returned to the browser, it is only a partial response.  Also the
connection is closed on both sides by the proxy.

What version of the product are you using? On what operating system?
webchat2 on Debian 5.0
firefox 3.5
not sure of what proxy

Please provide any additional information below.

I know this isn't really a defect, just wondering if anyone had any ideas
for workarounds?  I realize there probably isn't a viable solution besides
using a different comet architecture (e.g. longpolling) but just wanted to
throw this out there.

Original issue reported on code.google.com by jbel...@gmail.com on 1 Sep 2009 at 5:13