#7581: Middleware accessing HttpResponse.content breaks streaming HttpResponse
objects.
---------------------------------------------+------------------------------
Reporter: mrmachine | Owner: nobody
Status: new | Milestone: post-1.0
Component: Core framework | Version: SVN
Resolution: | Keywords: stream
HttpResponse
Stage: Design decision needed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------+------------------------------
Comment (by isagalaev):
> if a certain middleware CAN run without breaking a content generator
(e.g. GZip when not using WSGI), shouldn't it do so?
I don't think so. It would break feauture parity between mod_python and
WSGI and thus will make it harder for users to switch deployment scheme.
Furthermore WSGI requiring Content-Length is a good thing because
otherwise browsers won't show download progress. I think it's a bad side
effect.
> What about setting a boolean attribute consume_generator on HttpResponse
which defaults to True.
The point of my previous comment was that there shouldn't be a generic
attribute at all. Because generically it doesn't make any sense. I really
meant just this:
{{{
def my_view(request):
response = HttpResponse(open('somefile'))
if os.path.getsize('somefile') > 1024:
response.dont_gzip = True
class GzipMiddleware:
def process_response(self, request, response):
if getattr(response, 'dont_gzip'):
return
}}}
And similar attribute for CommonMiddleware about etag.
In other words, I think that the fact that certain two middleware can skip
their action in a very certain conditions should remain their own detail
and shouldn't affect other parts of the framework.
--
Ticket URL: <http://code.djangoproject.com/ticket/7581#comment:11>
Django Code <http://code.djangoproject.com/>
The web framework for perfectionists with deadlines
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
