ed 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
On 2 July 2014 15:42, Florian Apolloner wrote:
> 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 compatibil
2014-07-02 15:36 GMT+02:00 Łukasz Rekucki :
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 rem
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
On Jul 2, 2014 2:09 PM, "Aymeric Augustin" <
aymeric.augus...@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 acc
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 a
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 jus
