-
Notifications
You must be signed in to change notification settings - Fork 10k
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
server: Flush headers when using wait=true and stream=true #877
Conversation
Many http clients will missbehave unless they get an initial http- response, even when long-polling. It also saves the user/client from having to handle headers on the first action of the watch, but rather handle the response immediately.
lgtm, do you have an example client that I can add to the changelog? |
lgtm |
Hi, actually i suppose most clients can handle it, as long as you give them a The clients i was working with was the standard client of erlang (httpc) Don't know if the patch is really necessary, it might make asynchronous 2014-07-07 23:31 GMT+02:00 Blake Mizerany notifications@github.com:
|
lgtm also. |
@rawn If headers are given they have a timeout for that already? |
The library i'm using currently is process oriented (most of erlang is) |
No idea if i answered your question btw. 2014-07-08 1:21 GMT+02:00 Christoffer Vikström chvi77@gmail.com:
|
@rawn And this patch helped relieve this blocking? Did you test it? |
Yes, it helped.
|
I'm writing a new erlang client for etcd, thats how i noticed.
|
@rawn great, thanks. Merging. |
server: Flush headers when using wait=true and stream=true
Thanks!
|
Many http clients will missbehave unless they get an initial http-
response, even when long-polling. It also saves the user/client from
having to handle headers on the first action of the watch, but rather
handle the response immediately.