In my opinion, the HTTP server’s Request.Body’s io.Reader should return an error on read when the request body ends unexpectedly, rather than having every use of the request body try to sanity check the length which seems cumbersome and error prone.
I believe it should, but it's likely a userspace proxy like HAProxy is in the way causing errors to be swallowed, as there's no way with the current sockets API to intentionally send an error over the wire.
Do you think so? I checked the Go http server code and my not-so-careful reading seems to confirm their suspicions: it just reads from the body io.Reader, which doesn't seem to validate length. (They DO use a limit reader to prevent DoSing with huge bodies, at least.)
Now if they were phoning out to a remote server, I’d assume some kind of fabric or load balancer. But I assume they’ve got a local etcd on each node or something along those lines so it is very possible that it’s all local networking.
Though in most cases, outside of this use case, I’d agree that this is not particularly useful because it would never be terribly reliable. I know for a fact Amazon ELB rewrites the entire request, as an example...
I was talking about getting an error when reading from io.Reader, like a TCP timeout. I was quite sure the error would bubble up, but it of course wouldn't if there was no error to begin with, with something like HAProxy in the way.
I haven't found the code yet but it should throw a line too long error for malformed chunked encoding.
The implementer can always compare the read bytes to the content-length themselves. I have a hard time believing without evidence that etcd's implementation is wrong at this stage..
