ConditionalGetMiddleware behavior improvement.
|Reported by:||penzoil||Owned by:||nobody|
|Component:||Core (Cache system)||Version:||master|
|Severity:||Normal||Keywords:||ETag, ConditionalGetMiddleware, patch_response_headers|
|Cc:||Forest Bond||Triage Stage:||Design decision needed|
|Has patch:||yes||Needs documentation:||no|
|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.
This fix will require a little bit of documentation change to explain the extra condition.
Change History (15)
comment:1 Changed 7 years ago by
|Patch needs improvement:||set|
|Triage Stage:||Unreviewed → Design decision needed|
comment:4 Changed 6 years ago by
|Patch needs improvement:||unset|
|Triage Stage:||Design decision needed → Unreviewed|