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 <[email protected]> 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 <[email protected]>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? >> > >
_______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
