<div dir="ltr">That's cool, you managed to get that done in a lot fewer code lines than I would have thought would be needed.<div><br></div><div>But I do not think that this patch alone will be enough to fix #3093. The new state that prevents the original problem will only be caught is req->req_body_status==REQ_BODY_CACHED, and that will only be caught if 'std.cache_req_body()' was called. That is not a prerequisite for the bug (even though it was used in the test case), and if it wasn't called, I believe we could then again reach a state where we on retry send a bereq with C-L, but send no req-body-bytes, eventually timing out. For this reason I think we need the code from the initial patch as well, that is keeping track of if there was a request body in the first place, and not allowing retries if it isn't available when we need it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Spotted along the way: Should we alloc std.cache_req_body() also<br>in vcl_backend_fetch{} ?</blockquote><div><br></div><div>Wouldn't that be too late for a lot of cases? On a pure background fetch, the client would've continued on its merry way by the time vcl_backend_fetch is run.</div><div><br></div><div>-Martin </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 24 Oct 2019 at 11:11, Poul-Henning Kamp <<a href="mailto:phk@phk.freebsd.dk">phk@phk.freebsd.dk</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">I'm on the train with shitty connectivity, so I will not attempt<br>
a pull request, but this is a proposed DTRT patch for 3093<br>
<br>
(Note that the vtc in 3093 fails, because this DTRT)<br>
<br>
Comments & Tests welcome.<br>
<br>
Spotted along the way: Should we alloc std.cache_req_body() also<br>
in vcl_backend_fetch{} ?<br>
<br>
<br>
-- <br>
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20<br>
phk@FreeBSD.ORG         | TCP/IP since RFC 956<br>
FreeBSD committer       | BSD since 4.3-tahoe<br>
Never attribute to malice what can adequately be explained by incompetence.<br>
_______________________________________________<br>
varnish-dev mailing list<br>
<a href="mailto:varnish-dev@varnish-cache.org" target="_blank">varnish-dev@varnish-cache.org</a><br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev" rel="noreferrer" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><table border="0" cellpadding="0" cellspacing="0" style="font-size:12px;line-height:1.5em;font-family:"Helvetica Neue",Arial,sans-serif;color:rgb(102,102,102);width:550px;border-top:1px solid rgb(238,238,238);border-bottom:1px solid rgb(238,238,238);margin-top:20px;padding-top:5px;padding-bottom:5px"><tbody><tr><td width="100"><a href="http://varnish-software.com" target="_blank"><img src="http://www.varnish-software.com/static/media/logo-email.png"></a><span></span><span></span></td><td><strong style="font-size:14px;color:rgb(34,34,34)">Martin Blix Grydeland</strong><br>Senior Developer | Varnish Software<br></td></tr></tbody></table></div></div></div></div></div></div>