This is in reference to this ticket: 
https://code.djangoproject.com/ticket/17092

There is a patch there to fix the specific use case of needing to disable 
django's fix_location_header for certain responses in a CGI compliant 
environment. Because of the way that response_fixes work you can't just 
implement middleware to bypass them. So the patch in that ticket adds an 
attribute to the response object that allows that 'fix' to be bypassed when 
the handler processes the response. In that ticket aagustin brought up that 
this might be better fixed by removing response_fixes from the base handler 
and instead implementing them in common middleware making it easier to 
add/remove or customize on a project by project basis rather than adding 
attributes to the response object.

Before going any further I wanted to see what the preferred approach would 
be.

I see 4 options.

1) Remove the concept of response_fixes from base handlers entirely and 
re-implement what we currently have as middleware. This would break any 
customized handlers that may be relying on  response_fixes as well as the 
current redirect behavior for projects that aren't using common middleware.

2) Leave response_fixes as a feature of handlers but move the 
fix_location_header functionality into middleware only breaking 
applications that aren't using common middleware.

3) Apply the patch as is, address any future problems with response_fixes 
as they come up.

4) Do nothing, projects that want the CGI compliant behavior can hack 
django.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d7b08325-6809-4b63-a948-4963bd590d5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to