Hey guys, +1 as well, this is really great work, on both patches!
Modifying the middleware stack mid request would be very useful for us. We currently run 3 copies of the same code, with essentially different urls.py and middlewares loaded, each one is used to run a variation of the site, for example www/mobile web and api, and have slightly different requirements, which are handled in middlewares, for example api calls are authenticated by access tokens and www/mobile use cookies. Ideally we'd love to consolidate our deployment into a single set of python web workers, but to date its been a little too complex to be worth it. We could however use the url dispatching patch and PR1 to write a middleware which could load in the necessary middleware stack based on the requirements of each request. So my preference therefore would be for PR1 as I can see a few edge cases it would enable solutions for. Mat On Friday, 8 January 2016 16:01:15 UTC, Florian Apolloner wrote: > > PR1 (allows changing the middlewares during the middleware run): > https://github.com/django/django/pull/5591 > PR2 (static middleware chain, seems simpler and probably the way to go): > https://github.com/django/django/pull/5949/ > > On Friday, January 8, 2016 at 4:55:08 PM UTC+1, Florian Apolloner wrote: >> >> Haha, I was so focused on my previous approach that I forgot, that I >> could just chain them during setup (thanks knbk). So the question remaining >> now: Do we want to be able to change middlewares per request or not :D I >> guess I'll submit a second PR with the non-request usage. >> >> On Friday, January 8, 2016 at 3:29:01 PM UTC+1, Florian Apolloner wrote: >>> >>> Mhm, >>> >>> I currently see no easy way to give *get_response* access to the list >>> of middlewares like done in >>> https://github.com/django/django/pull/5591/files#diff-dbd7d9159676b15fc9a096b0adb919e9R122 >>> >>> and following lines. The reason is that providing *get_response* at >>> setup/init time means it has to be one "static" method which is the same >>> for all requests. Aside from using a thread local or stashing the >>> middleware list on the request, this method has no way of getting access to >>> the current middleware chain. Any ideas? >>> >>> Cheers, >>> Florian >>> >> -- 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/6c61f7b1-0d8b-4cf4-8499-af167713cde6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
