ectations, 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.
>
> - `condition
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
>>
2014-07-02 15:36 GMT+02:00 Łukasz Rekucki <lreku...@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".
Th
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
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
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
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