Re: Adding a middleware to match cookies
the specific case I am talking about deals with google analytics cookies, which are different for every user and sent with the request. When accessing request.user, I really only care about sessionid and csrftoken, if present. So sending a vary by cookie header back will cause all the unauthed/unsessioned users to miss the cache because of the GA cookies. Since I have no use for these cookies in my code, and they are only used for external requests to GA, eliminating them somewhere (earlier the better) should improve cache hits, right? On Saturday, January 7, 2017 at 8:25:10 PM UTC+9, Florian Apolloner wrote: > > Hi Jeff, > > On Saturday, January 7, 2017 at 3:50:56 AM UTC+1, Jeff Willette wrote: >> >> What if there was an optional middleware early in the request processing >> that matched cookies based on a regex in settings and then modified the >> header to only include the matched cookies? >> > > I do not see how this would help -- you'd still have to set "Vary: Cookie" > on the response as soon as you are accessing request.user. Or is the goal > of this to allow Django's internal page caching stuff to ignore some > cookies? That seems doable, but very very dangerous. > > This issue reminds me of another issue I came up with (or as Carl puts it: > "…presenting the hypothetical case that exposed this bug."), namely > https://code.djangoproject.com/ticket/19649 -- Basically as soon as > Django accesses __any__ cookie we should set "Vary: Cookie", with all the > downsides this entails. I think we finally should fix that and put a fix > for it into the BaseHandler. > > What would be great would be an HTTP header which allowed for something > ala "Cache: if-request-did-not-have-cookies" -- usually it is pointless to > cache __anything__ with cookies anyways. That said, with all the analytics > super cookies out there, there are not many pages without cookies anymore :( > -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/7d443c5e-5f70-421f-a44c-82dd6d71e477%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Adding a middleware to match cookies
Carl, thanks for the reply. Wy would this not help the efficiency of the downstream caches? Is it because the request has already passed through them with the cookies intact? and when it comes back through the response they have no way to know they have been stripped? On Saturday, January 7, 2017 at 12:02:30 PM UTC+9, Carl Meyer wrote: > > Hi Jeff, > > On 01/06/2017 06:21 PM, Jeff Willette wrote: > > I understand that calling is_authenticated on a user will require the > > session to be accessed and the vary by cookie header to be in the > > response, but if I understand how caching systems work then this will > > cause all cookies in the request to be taken into account, correct? > > Yes. HTTP doesn't provide any way to say "vary only on this cookie, not > the others." Be nice if it did! > > > What if there was an optional middleware early in the request > > processing that matched cookies based on a regex in settings and then > > modified the header to only include the matched cookies? > > > > That way...the unauthed users request will vary by cookies, but we > > would have removed all inconsequential cookies so all unauthed users > > will have the same set of cookies (likely none), and authed users > > will have (sessionid) or whatever else you wish to match and everyone > > will be happily cached correctly. > > > > Is there a hole in my thinking anywhere? Would this work as I > > expect? > > I think it could work, yeah. It won't help the efficiency of any other > downstream HTTP caches, but they would still be safe (not serve anyone > the wrong response). And you should be able to help efficiency of > Django's own cache this way, if you strip cookies that Django / your > code doesn't care about before the request ever reaches the caching > middleware. Try it and experiment! > > Carl > > -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/b2b46018-f3e0-45c4-9161-cd68ecc9a1ea%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Adding a middleware to match cookies
I recently proposed a bad fix (https://code.djangoproject.com/ticket/27686) but I think the problem still remains and I might have a way arpund it. I understand that calling is_authenticated on a user will require the session to be accessed and the vary by cookie header to be in the response, but if I understand how caching systems work then this will cause all cookies in the request to be taken into account, correct? The idea in the ticket about using ajax requests is good, but i would prefer to keep the page differences in the django logic and avoid an extra request to the server on every page load. What if there was an optional middleware early in the request processing that matched cookies based on a regex in settings and then modified the header to only include the matched cookies? That way...the unauthed users request will vary by cookies, but we would have removed all inconsequential cookies so all unauthed users will have the same set of cookies (likely none), and authed users will have (sessionid) or whatever else you wish to match and everyone will be happily cached correctly. Is there a hole in my thinking anywhere? Would this work as I expect? -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/422d07a9-daac-4b3d-9f85-5cdd338fd8a4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
optional middleware to eliminate cookies in request header
I just posted this and I didn't see it pop up in the group, so I am sorry if this is a repost. I recently submitted a bad fix (https://code.djangoproject.com/ticket/27686#comment:6). I made a mistake in thinking about how the caching system works but I think I have another solution to the problem. The solution in the ticket is good, but I would prefer to avoid another request to get authed content and I would like to keep most of the logic in django and continue to use the is_authenticated method. What if there was a middleware early on in the request processing that would match the cookie header by a regex in settings. If it did not find one of the matches than it would eliminate the cookie header. This way the vary by cookie header will still be sent, but inconsequential cookies will be removed so that al unauthed users would have the same page cached (varied by cookie with no cookies) and authed users would have theirs cached correctly as well. Is there anything wrong with my thinking about how this would work? Do you think this is a good idea? -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/4fb1ca99-6144-40aa-b840-df514cefdcc2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
