Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not a defect. Question regarding buffering proxies. #24

Open
GoogleCodeExporter opened this issue Mar 13, 2015 · 0 comments
Open

Not a defect. Question regarding buffering proxies. #24

GoogleCodeExporter opened this issue Mar 13, 2015 · 0 comments

Comments

@GoogleCodeExporter
Copy link

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 [email protected] on 1 Sep 2009 at 5:13

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant