Value of builtin.vcl - vcl_recv on modern websites

Dridi Boukelmoune dridi at varni.sh
Wed Jul 12 14:28:35 CEST 2017


> Great blog post (that i haven't seen before), thanks for sharing its
> right on topic, looking forward to part 2

Thank you very much, really appreciated. The current draft for part 2
is complete but not really a good read. I'm having a hard time going
over arcane HTTP contradictions and I don't have time these days to
sit and write.

> It feels like one way or another a solution is going to be needed
> before vcl_recv in builtin.vcl to make the logic work on almost any
> web application.
>
> Im wondering if its more logical for new users to override (return)
> based based on explicit conditions that they define rather than move
> the cookie in and out of scope for different scenarios to achieve the
> same outcome (and have them forced to understand how we are being
> sneaky with the cookie to avoid the underlying cookie check).

It really depends. By default Varnish will pipe requests with unknown
methods because part of the poor design of HTTP is the lack of
semantics of the methods: if you don't already know a method, you
can't anticipate how to handle it. For example with a HEAD request you
may get a positive Content-Length but nevertheless no body. What if an
unknown method has some similar behavior? (this is also true for
response statues like 204.)

So let's imagine that you'd use Varnish in front of a webdav
application, you'd get a lot of legit methods that wouldn't go through
the state machine (straight to vcl_pipe) if you run through the
built-in vcl_recv{}.

> That said the "cookie shuffle" does keep the rest of the good logic in
> builtin vcl_recv in scope and saves lifting it up.
<snip>
> I like the trick personally, It avoids alot of muckyness in cookie management.

Yes, simplest solution I found in the "composing with the built-in" case.

> I still come back to whether its easier to teach than option 3 where
> there are explicit rules and the good code from builtin.vcl is now
> visible to the user in their default.vcl
<snip>
> Depending on the customers skills and application complexity I have
> been recommending this approach. It seems to feel more logical to new
> users of Varnish.

Correct, the built-in vcl_recv{} would still show up with the
`vcl.show -v` command but it would indeed be defeated.

> Agreed, though nothing is simple! a tricky topic, Thanks for your
> views and letting me know this is an area you have crossed recently!

Too frequently I'm afraid ;-)



More information about the varnish-misc mailing list