Response Fixes

[peter]

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.

[Aymeric Augustin]

I find it wrong to alter the response created by the developer unconditionally and not provide any escape hatch. Therefore option 1 is my favorite. I'm proposing to documenting the backwards incompatibility in the release notes.

It will only affect project that do not use CommonMiddleware. There are very few use cases for not using it. I expect that developers who made that choice will know why and be able to adjust for the change.

-- 

Aymeric.

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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.

--
Aymeric.

[Łukasz Rekucki]

On Jul 2, 2014 2:09 PM, "Aymeric Augustin" <aymeric....@polytechnique.org> wrote:
>
> I find it wrong to alter the response created by the developer unconditionally and not provide any escape hatch.

It doesn't just alter it, but makes it conform to HTTP standard. While most browsers will accept relative urls, I don't think Django should sacrafice backwards compatibility for an arcane CGI feature.

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANE-7mUjVR-uSZv-Du-p%3Dz%2BVF2LBdRKOjCEcX0_82qXe%3DWtzkg%40mail.gmail.com.

[Florian Apolloner]

On Wednesday, July 2, 2014 3:36:22 PM UTC+2, Łukasz Rekucki wrote:

It doesn't just alter it, but makes it conform to HTTP standard. While most browsers will accept relative urls, I don't think Django should sacrafice backwards compatibility for an arcane CGI feature.

Internal redirects are imo an important feature to support, maybe not by default, but the response should be able to say "I know what I am doing".
 

[Aymeric Augustin]

2014-07-02 15:36 GMT+02:00 Łukasz Rekucki <lrek...@gmail.com>:

It doesn't just alter it, but makes it conform to HTTP standard.

As usual, given a different set of expectations, auto-fix is auto-break.

We recently removed two of the four unconditional response "fixes".

The remaining ones are:

- `fix_location_header`: at least for some people, it's an issue. That's

  why we're having a discussion.

- `conditional_content_removal`: there's a variety of scenarios where

  it fails. For instance, if you have a reverse proxy in front of your app

  that performs gzipping, to handle HEAD requests correctly, it must

  get the response body, compress it, figure out its length, and add it

  to the Content-Length header.

That's why I believe the concept of unconditional response "fixes" in

itself is flawed.

--
Aymeric.

[Łukasz Rekucki]

Sure and that's why Nginx has X-Accel-Redirect. The problem with this
feature is that it requires using an (yet[1]) invalid value for an
already HTTP header. Personally, I would workaround this by adding my
own header like X-CGI-Forward and then make the CGI-Django wrapper
override Location with its value if it's present.

[1]: It seems the next version of HTTP 1.1 will allow non-absolute
URLs, but obviously CGI applications won't be able to return them to
the client because of this feature ;).

>
>
> --
> 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-develop...@googlegroups.com.
> To post to this group, send email to django-d...@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/19074151-e0eb-4925-90fe-9b1e5eedfd50%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.


--

Łukasz Rekucki

[Łukasz Rekucki]

On 2 July 2014 21:14, Aymeric Augustin

I'm not saying it isn't, but sadly they are already there. I just
wanted to say, that I think this feature is not worth the potential
breakage. I'm sure there are better ways to achieve this without using
CGI or mod_wsgi.

>
> --
> Aymeric.
>
> --
> 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-develop...@googlegroups.com.
> To post to this group, send email to django-d...@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/CANE-7mWfbz__6_18S9Ak098Byp9NuJLumvCy3YKbq6SXUbFtTQ%40mail.gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.



--

Łukasz Rekucki