summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorWim Leers2015-11-26 15:33:33 +0100
committerWim Leers2015-11-26 15:36:08 +0100
commitb0c51b6925accd9f891a2c5e5ea986881f0a804b (patch)
tree26b55979ac59bdbf834f3cd50f9bea25f02e8e4e
parent5d77cd698af504b424b70209759b6bf10448c3f0 (diff)
Issue #2623674: Document BigPipe + reverse proxy
-rw-r--r--README.md24
1 files changed, 24 insertions, 0 deletions
diff --git a/README.md b/README.md
index dc7bfb3..e4a87a7 100644
--- a/README.md
+++ b/README.md
@@ -36,3 +36,27 @@ the BigPipe module is built upon.
- https://www.drupal.org/developing/api/8/render/arrays/cacheability/auto-placeholdering
- https://www.drupal.org/documentation/modules/dynamic_page_cache
- https://www.facebook.com/notes/facebook-engineering/bigpipe-pipelining-web-pages-for-high-performance/389414033919
+
+## Varnish
+
+- BigPipe uses streaming, this means any proxy in between should not buffer the response: the origin needs to stream directly to the end user.
+- Hence Varnish should not buffer the response, or otherwise the end result is still a single flush, which means worse performance again.
+- BigPipe responses contain the header `Surrogate-Control: no-store, content="BigPipe/1.0"`.
+
+Therefore the following VCL makes Varnish compatible with BigPipe:
+
+```
+vcl_fetch {
+ if (beresp.Surrogate-Control ~ "BigPipe/1.0") {
+ set beresp.do_stream = true;
+ set beresp.ttl = 0;
+ }
+}
+```
+
+
+## Other (reverse) proxies
+
+Other (reverse) proxies, including CDNs, need to be configured in a similar way.
+
+Buffering will nullify the improved front-end performance. This means that users accessing the site via a ISP-installed proxy will not benefit. But the site won't break either.