| 1 | | The patch here seems to go against the advice from core committers in the past regarding middleware having to perform repetitive behaviour such as interrogate a response to find out whether or not it can access or replace the content (e.g. checking if the content is a string or a generator, for streaming responses). |
| 2 | | |
| 3 | | If we start heading down this path of middleware being required to ask each response if it has rendered content (or generator content) and conditionally performing an action, where does it end? |
| 4 | | |
| 5 | | If middleware can't be certain that response.content will be a string, then ALL bundled and 3rd party middleware will always need to perform this (and possibly other) checks before taking conditional or no action. |
| 6 | | |
| 7 | | There was some discussion in the past about the best way to conditionally disable middleware for a particular response or class of responses (e.g. streaming) without having to make every middleware perform these checks. But no consensus was ever reached. And with this issue now breaking the admin when used with etags, it seems we need to at least work-around it or roll back the change that introduced this breakage while the larger issues are examined. |
| 8 | | |
| 9 | | See http://groups.google.com/group/django-developers/browse_thread/thread/3e0d78b98498c159/f08036fb1e7fe6b9 and also #7581 for past discussions. |
| 10 | | |
| 11 | | I think that the solution should be for TemplateResponse to render it's content when `.content` is accessed, in combination with a mechanism for people to specify that certain middleware should not run for certain responses. This could lead to unexpected behaviour though, if a user is attempting to replace a template before rendering in another middleware. |
| 12 | | |
| 13 | | Alternatively, there could be a generic way to defer processing of a certain middleware in `HttpResponse` subclasses, such as `TemplateResponse` (and maybe a new `StreamingResponse`). But it is not practical for an `HttpResponse` subclass to know all the middleware that it may be exposed to. There are also complex issues with general capabilities checking for responses and middleware. |
| | 1 | Nevermind. I didn't fully understand the issue. |