Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
V
varnishevent3
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
uplex-varnish
varnishevent3
Commits
9469d952
Commit
9469d952
authored
Jan 24, 2011
by
Poul-Henning Kamp
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Update with ESI+GZIP section
parent
9a57367f
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
73 additions
and
2 deletions
+73
-2
gzip.rst
doc/sphinx/phk/gzip.rst
+73
-2
No files found.
doc/sphinx/phk/gzip.rst
View file @
9469d952
...
...
@@ -36,11 +36,13 @@ hash lookup.
Varnish will not do any other types of compressions than gzip, in particular
we will not do deflate, as there are browser bugs in that case.
Before vcl_
hit
{} is called, the backend requests Accept-Encoding is
Before vcl_
miss
{} is called, the backend requests Accept-Encoding is
always set to:
Accept-Encoding: gzip
Even if this particular client does not support
To always entice the backend into sending us gzip'ed content.
Varnish will not gzip any content on its own (but see below), we trust
...
...
@@ -63,6 +65,9 @@ Even if the client does not support gzip, you can force the A-C header
to "gzip" to save bandwidth between the backend and varnish, varnish will
gunzip the object before delivering to the client.
In vcl_miss{} you can remove the "Accept-Encoding: gzip" header, if you
do not want the backend to gzip this object.
In vcl_fetch{} two new variables allow you to modify the gzip-ness of
objects during fetch:
...
...
@@ -89,4 +94,70 @@ typical use would be:
GZIP and ESI
------------
TBD.
First, note the new syntax for activating ESI:
sub vcl_fetch {
set beresp.do_esi = true;
}
In theory, and hopefully in practice, all you read above should apply also
when you enable ESI, if not it is a bug you should report.
But things are vastly more complicated now. What happens for
instance, when the backend sends a gzip'ed object we ESI process
it and it includes another object which is not gzip'ed, and we want
to send the result gziped to the client ?
Things can get really hairy here, so let me explain it in stages.
Assume we have a ungzipped object we want to ESI process.
The ESI parser will run through the object looking for the various
magic strings and produce a byte-stream we call the "VEC" for Varnish
ESI Codes.
The VEC contains instructions like "skip 234 bytes", "deliver 12919 bytes",
"include /foobar", "deliver 122 bytes" etc and it is stored with the
object.
When we deliver an object, and it has a VEC, special esi-delivery code
interprets the VEC string and sends the output to the client as ordered.
When the VEC says "include /foobar" we do what amounts to a restart with
the new URL and possibly Host: header, and call vcl_recv{} etc. You
can tell that you are in an ESI include by examining the 'req.esi_level'
variable in VCL.
The ESI-parsed object is stored gzip'ed under the same conditions as
above: If the backend sends gzip'ed and VCL did not ask for do_gunzip,
or if the backend sends ungzip'ed and VCL asked for do_gzip.
Please note that since we need to insert flush and reset points in
the gzip file, it will be slightly larger than a normal gzip file of
the same object.
When we encounter gzip'ed include objects which should not be, we
gunzip them, but when we encounter gunzip'ed objects which should
be, we gzip them, but only at compression level zero.
So in order to avoid unnecessary work, and in order to get maximum
compression efficiency, you should:
sub vcl_miss {
if (object needs ESI processing) {
unset bereq.http.accept-encoding;
}
}
sub vcl_fetch {
if (object needs ESI processing) {
set beresp.do_esi = true;
set beresp.do_gzip = true;
}
}
So that the backend sends these objects uncompressed to varnish.
You should also attempt to make sure that all objects which are
esi:included are gziped, either by making the backend do it or
by making varnish do it.
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment