Varnish 4.0 and IMS oddity

[Mark Moseley]

I guess this is probably the asynchronous fetches in varnish 4, so
presumably expected behavior.

I really love the IMS feature btw :)


On Sat, Apr 19, 2014 at 9:11 AM, Mark Moseley <moseleymark at gmail.com> wrote:

> 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/20140420/8d994a5b/attachment.html>