--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/81484ff1-552e-4103-9fa8-8a3348512b84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
On Fri, 25 Jan 2019 at 14:46, Linus Lewandowski <linus.le...@netguru.pl> wrote:--Right now, it's hard to report Vary header correctly. Headers might get accessed in many different places, like middlewares, subroutines (which can't use patch_vary_headers as they don't have access to the response object), etc - and all those cases should be reflected in the Vary header, or something might get cached incorrectly.However, thanks to the newly added request.headers property (see https://code.djangoproject.com/ticket/20147 and https://github.com/django/django/commit/4fc35a9c3efdc9154efce28cb23cb84f8834517e), we now have a single place which is used to access request headers. We can track which ones were accessed, and then set Vary header automatically, for example in a middleware.What do you think about:
1) adding some code to track accessed headers in request.headers,
2) adding a new middleware (or expanding an existing one), that sets the Vary header based on 1),
3) deprecating patch_vary_headers function and vary_on_headers/vary_on_cookie decorators and recommending to use request.headers instead?Thanks,LinusPS. This is a follow-up to the https://code.djangoproject.com/ticket/28533 ticket.
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/81484ff1-552e-4103-9fa8-8a3348512b84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--Adam--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/LlQtbOm_YWw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3uDHaDywYFa6fM_-jJw8j81yoTP9%3DyLO2Rx2JDOk45jw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3uDHaDywYFa6fM_-jJw8j81yoTP9%3DyLO2Rx2JDOk45jw%40mail.gmail.com.
True, probably a way to access headers without marking them as used would be required - maybe something like request.headers.get(XYZ, vary_response=False).
However, right now people are commonly forgetting to patch Vary, which leads to problems with caching. This way - this won't happen ever again; but in some cases, we might make caching less efficient than possible, because somebody used request.headers[XYZ] and not request.headers.get(XYZ, vary_response=False). Given these two cases - I feel that working correctly is more important than perfectly-efficient caching - but opinions here may differ.
My immediate thought here is: if people already aren't taking the time to patch using the existing mechanism, they also aren't going to take the time to opt out of patching. So what you're proposing is effectively still "any accessed header patches Vary". And that seems like it's as bad as the problem it's trying to solve.