Open
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi @mnot
This is the PR I mentioned in #49 - adding a test to validate what I have called "dynamic vary". This issue came to my attention during building a traffic management system, we determined that nginx does not create cache object variants when the origin issues a
varyheader whose value is dependent on the value of a request header (we have some use cases which require this). Failure to support "dynamic vary" can result in flip-flopping - nginx simply overwrites the single cached object with the new object, this obviously ruins cache offload under transitional circumstances. As a ref for nginx, please see this ticket: https://trac.nginx.org/nginx/ticket/955.My intention through adding this PR is twofold:
Varnish does support "dynamic vary" according to our tests.
I'm sure you'll see what I'm trying to achieve by looking at the added test, I believe I've correctly defined the behaviour but please let me know if you think I've done the wrong thing. Currently I see an error on request 3 which I expect not to be cached and indeed it looks to me like nginx did not serve a cached response for that request (I added a custom response header to nginx whose value is
$upstream_cache_status, this saysMISS):I suspect that perhaps the server component of
cache-testsmight be doing the wrong thing here, would you agree? I'll happily do some work on it if you think that is likely to be the issue and if you're interested in this PR so if you could let me know when you have moment, that'd be great.Many thanks and apologies for the epic message :-)
Neil