ConditionalGetMiddleware behavior improvement.
|Reported by:||penzoil <fredericbochmann@…>||Owned by:||nobody|
|Component:||Core (Cache system)||Version:||master|
|Has patch:||yes||Needs documentation:||yes|
|Needs tests:||yes||Patch needs improvement:||no|
This patch is intended to improve the behavior of the django.middleware.http.ConditionalGetMiddleware middleware. When a particular django view has at least two decorators that work with redirecting behavior, Firefox will send a ETag that seems to be valid since the response is nothing more than a Location redirect, thus the content-length is 0 and the ETag is valid for the two steps created by the two decorators that redirect the user to different pages (Example decorator : @login_required and another that acts very similarly).
The bug is that the browser will receive a Not Modified header once the users passes the first decorator when he gets redirected by to the original view.
The FIX: The fix changes the behavior of the django.middleware.http.ConditionalGetMiddleware to not send a 304 response code if the content-length is 0 or undefined.
I'm not sure if it's proper, but it seems good of a fix and it actually fixes my issue.
So, I just wanted to shared it, hopefully it can make it in the code-base.