In the first part of this blog series, we saw how to rewrite URLs to seamlessly redirect people to where the content actually is. Today we are going to see how Varnish can help you do the same thing NOT seamlessly, using one of the built-in facilities of HTTP.
Note: this article is the first in a two-part series, you can find the second post here.
Cool urls don't change, it is said. And according to itself, that URL must be pretty cool, because it hasn't changed in 18 years! The gits of it is: "the net is vast and infinite" and people will reference your site so you should be a good citizen and not shuffle resource URLs because we'll get dangling links and dangling links are bad, m'kay?
Not long ago, the New York Times posted a piece, “Testing Varnish Using Varnishtest”, in their tech blog. The writer explains the challenges of working with legacy code that was not designed for continuous delivery practice and states upfront as an introduction to his work with Varnish: “One of the tougher challenges I faced was learning how to test the systems I inherited, and one of those platforms I inherited was our Varnish stack.” He goes on to explain in more detail why this posed a significant learning curve for him, in part because of Varnish’s own configuration language, VCL. VCL enabled a lot of flexibility, but then he found that he struggled at first with testing the VCL.