Varnish 4.0 and IMS oddity

Mark Moseley moseleymark at gmail.com
Sat Apr 19 18:11:38 CEST 2014


Finally got a chance to play around with this some more.

It seems like if I turn off grace, it works like I'd expect it to (i.e.
non-304 backend requests override whatever is stored in varnish by 'keep').
It sort of makes sense in a grace way but could be a surprise if someone
wasn't expecting it. That is, that grace would trump the non-304 in the IMS
request for a request or two.

Actually, maybe it's just a grace thing. Even with IMS/keep off, I'm still
seeing at least one stale response, which sounds very much like grace,
though I'd only expect it to kick in for a sick backend or multiple
clients. This is a test box, so I'm the only one hitting the server (and
using curl, so only a single request is hitting it at a time). I've got
grace on in 3.x and things work like I'd expect there. Perhaps just a
behavior change in 4.x?

I've not tested it super extensively yet, so I could be wrong. I've
switched it back and forth a couple of times and with grace on, it does the
same as above; with grace off, it acts like I'd expect. Though as always,
my setup is probably more than a bit wonky.


On Sat, Apr 12, 2014 at 10:51 PM, Mark Moseley <moseleymark at gmail.com>wrote:

> Hi. I'm testing out Varnish 4.0 finally. I'm super excited about the IMS
> stuff and am dying to use it. And a big congratulations on the 4.0 release.
>
> I was playing with porting our shared hosting configuration to 4.0 and ran
> into a slight weirdness with IMS. Keeping in mind that we do a number of
> things to make things play nicely with the fact that we have no idea what
> our customers might be doing (and therefore have to jump through a bunch of
> crazy hoops to make sure we don't return things like authenticated content
> to unauthenticated users), this could very easily be something weird with
> our particular setup. I've re-run the test a bunch of times and seen the
> same thing each time.
>
> Here's the scenario:
>
> * I have IMS up and running and working. Other than this one particular
> oddity, everything else IMS-related seems to be working great and I'm
> greatly looking forward to using it. The test page I'm using deliberately
> returns a TTL of 1 second to make testing easier.
>
> * As a mockup of a customer doing something like cookie-base
> authentication, or IP-based .htaccess authentication, I wrote up a simple
> rewrite rule to return a 403 if a certain cookie was missing.
>
> * I turn off the rewrite rule
>
> * Do a request to that page a few times with the expected 200 from the
> backend. On the 2nd and subsequent reqs, the IMS stuff kicks in. BTW, is
> the client getting a "HTTP/1.1 200 Not Modified" the expected behavior? I
> know the strings after the status code are completely arbitrary but it
> looked a bit odd.
>
> * I turn the rewrite rule back *on*
>
> * Do the request again. Here's where it gets odd.
>
> * Varnish does an IMS request to the backend
>
> * The backend responds with a 403 as expected.
>
> * Varnish replies to the client with a HTTP/1.1 200 Not Modified
>
> I would expect an error status (or really anything that's not a 304) to
> fail the IMS test on Varnish's side and that it would then return the 403
> to the client. Something weird about what I'm doing/abusing?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20140419/d177701f/attachment.html>


More information about the varnish-misc mailing list