<div dir="ltr">In our case etcd (and go's net/http) would accept a PUT/POST request from an HTTP request with no body despite there being a Content-Length header. This combined with our python client sending headers as a searate packet from the body allowed this to trigger. We changed the way we use our python client to send the full request in a single packet where possible and updated out consumers to handle corrupt entries. We'll also be filing bugs with the upstreams soon.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 22, 2020 at 9:30 AM Carsten Bormann <<a href="mailto:cabo@tzi.org">cabo@tzi.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-03-21, at 05:04, Jay Ashworth via Outages <<a href="mailto:outages@outages.org" target="_blank">outages@outages.org</a>> wrote:<br>
> <br>
> Do I correctly understand, then, that the root cause was the broken golang library function / routine?<br>
<br>
I wouldn’t put it this way.  It seems the root cause was a protocol that relied on a TCP connection always completely transporting a message, and not checking that transported message for completeness before putting it to use.  No library function on the receiving end can check that the sending application did not crash in mid-transmission and seemingly did an orderly close.<br>
<br>
The message for protocol design 101: Do not use a TCP connection as the outer envelope, always use something transported inside that connection to properly delimit its end.<br>
(Ironically, the JSON encoding used in this instance does provide such delimiting in most ways of using it; apparently it just wasn’t checked here before relying on a successful transfer.)<br>
<br>
That message has been learned the hard way in multiple spaces; e.g., look up how TLS gained the closed_notify “closure alert”.<br>
<br>
Grüße, Carsten<br>
<br>
</blockquote></div>