-
Notifications
You must be signed in to change notification settings - Fork 29
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
Some http responses come back from http_client mangled #184
Comments
I see what you mean, due how traffic interception works, sometimes you can get partial messages. In previous version validation was done by golang http library, now we need something similar. Can you approximately say what percent of bad requests it shows on your data? |
Ah I see that I misunderstood a bit. Now I get what you mean. I will try to create test which replicate this behavior. On Friday, July 31, 2015, David Taylor notifications@github.com wrote:
Sincerely yours Leonid Bugaev |
I think that problem happens because response buffer too small, and if body larger then buffer, parts of unread responses gets read during next call, corrupting data. Frankly using ioutil.ReadAll just hangs tests fro me... |
Replicated with test, and fixed #185 |
I think response bodies are only looked at by the elastic plugin so this probably isn't a big deal for most users, but it looks like http_client sometimes corrupts responses.
I modified http_output.go to record and send
proto.Status(resp)[0]
to graphite, and then observed some really strange values. After a little digging, I added a panic if the first 5 bytes ofresp
weren'tHTTP/1.1
and discovered that sometimes they indeed were not (they looked like the middle of a response).Our responses are on the large side, so I tried increasing the size of
respBuff
in http_client.go, but to no effect. I then tried swapping thec.conn.Read(c.respBuf)
forioutil.ReadAll(c.conn)
which fixed it.The text was updated successfully, but these errors were encountered: