#3093 proposed patch

[Martin Blix Grydeland]

That's cool, you managed to get that done in a lot fewer code lines than I
would have thought would be needed.

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.

Spotted along the way: Should we alloc std.cache_req_body() also
> in vcl_backend_fetch{} ?


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.

-Martin

On Thu, 24 Oct 2019 at 11:11, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> I'm on the train with shitty connectivity, so I will not attempt
> a pull request, but this is a proposed DTRT patch for 3093
>
> (Note that the vtc in 3093 fails, because this DTRT)
>
> Comments & Tests welcome.
>
> Spotted along the way: Should we alloc std.cache_req_body() also
> in vcl_backend_fetch{} ?
>
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>


-- 
<http://varnish-software.com> *Martin Blix Grydeland*
Senior Developer | Varnish Software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20191024/137519e9/attachment.html>