The ESI_VDP would double-close sessions when a flush error happened
before an ESI include at one level, and then again at a higher level.
Fixed by not closing the session in this case, as that will be taken
care of at the end of delivery anyways when V1L_FlushRelease is
called.
Fixes: #1737
---
bin/varnishd/cache/cache_esi_deliver.c | 1 -
bin/varnishtest/tests/r01737.vtc | 43 ++++++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+), 1 deletion(-)
create mode 100644 bin/varnishtest/tests/r01737.vtc
diff --git a/bin/varnishd/cache/cache_esi_deliver.c
b/bin/varnishd/cache/cache_esi_deliver.c
index aa011b6..72a7763 100644
--- a/bin/varnishd/cache/cache_esi_deliver.c
+++ b/bin/varnishd/cache/cache_esi_deliver.c
@@ -317,7 +317,6 @@ VDP_ESI(struct req *req, enum vdp_action act, void **priv,
r = (void*)strchr((const char*)q, '\0');
AN(r);
if (VDP_bytes(req, VDP_FLUSH, NULL, 0)) {
- SES_Close(req->sp, SC_REM_CLOSE);
ecx->p = ecx->e;
break;
}
diff --git a/bin/varnishtest/tests/r01737.vtc b/bin/varnishtest/tests/r01737.vtc
new file mode 100644
index 0000000..66c5aee
--- /dev/null
+++ b/bin/varnishtest/tests/r01737.vtc
@@ -0,0 +1,43 @@
+varnishtest "#1737 - ESI sublevel session close"
+
+# Build a esi request tree that fails on flush before include at two different
+# levels. Synchronize a client close after the response headers have been
+# received by the client. This produces write erros for the body parts in all
+# fragments.
+server s1 {
+ rxreq
+ txresp -body {<esi:include src="/bar"/><esi:include src="/bar"/>}
+ sema r1 sync 2
+
+ rxreq
+ delay 1
+ txresp -body {<esi:include src="/baz"/>22<esi:include src="/baz"/>}
+
+ rxreq
+ txresp -body {1}
+
+ rxreq
+ expect req.url == "/check"
+ rxresp
+} -start
+
+varnish v1 -vcl+backend {
+ sub vcl_backend_response {
+ set beresp.do_esi = true;
+ }
+} -start
+
+# Send request, read response headers then close connection
+client c1 {
+ txreq
+ rxresp -no_obj
+ sema r1 sync 2
+} -run
+
+delay 3
+
+# Check that Varnish is alive
+client c1 {
+ txreq
+ rxresp
+} -run
--
2.1.4
_______________________________________________
varnish-dev mailing list
[email protected]
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
