<div dir="ltr">Finally got a chance to play around with this some more.<div><br></div><div>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. </div>
<div><br></div><div>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?</div>
<div><br></div><div>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.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 12, 2014 at 10:51 PM, Mark Moseley <span dir="ltr"><<a href="mailto:moseleymark@gmail.com" target="_blank">moseleymark@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div>
<br></div><div>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.</div>

<div><br></div><div>Here's the scenario:</div><div><br></div><div>* 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.</div>

<div><br></div><div>* 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.</div>

<div><br></div><div>* I turn off the rewrite rule</div><div><br></div><div>* 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.</div>

<div><br></div><div>* I turn the rewrite rule back *on*</div><div><br></div><div>* Do the request again. Here's where it gets odd.</div><div><br></div><div>* Varnish does an IMS request to the backend</div><div><br></div>

<div>* The backend responds with a 403 as expected.</div><div><br></div><div>* Varnish replies to the client with a HTTP/1.1 200 Not Modified</div><div><br></div><div>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?</div>

</div>
</blockquote></div><br></div>