#33588: @never_cache and @cache_page decorators are applied out of order for
TemplateResponse.
-------------------------------------+-------------------------------------
Reporter: Jacek Wojna | Owner: noneNote
Type: Bug | Status: assigned
Component: Core (Cache system) | Version: 4.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
cache,never_cache,cache_page,TemplateResponse,make_middleware_decorator|
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by noneNote):
{{{
@never_cache
@cache_page(3600)
def tem_view(request):
r = random.randint(1000, 9999)
return TemplateResponse(request, 'index.html', context=dict(value=r))
}}}
Here is what going on at 1st request,
**never_cache** -> **CacheMiddleware.process_request**[no cache found] ->
response.add_post_render_callback(CacheMiddleware.process_response) ->
**add_never_cache_headers(response)** -> after render calling
CacheMiddleware.process_response but returning response without setting
cache because of this,
{{{
if "private" in response.get("Cache-Control", ()):
return response
}}}
Suppose we somehow set cache, Here, what going to happen on at 2nd
request,
**never_cache** -> **CacheMiddleware.process_request**[cache found] ->
**add_never_cache_headers(response)**
What is the problem:
1) **never_cache**, **cache_control**, **last_modified** setting the
headers immediately while the cache is going to be set after **render()**,
Thus cache-Control, and other headers are present at the time of setting
the cache
2) there is no good way of detecting @decorator's orders and numbers,
which means we can not detect which and how many decorator users applied
before CacheMiddleware
3) deferring **CacheMiddleware.process_response** execution making whole
@decorator's orders **meaningless**.
Here is what I suggest as, a solution:
We already have **add_post_render_callback** so how about we add an
**add_apply_last_callback** to **HttpResponse** / **HttpResponseBase**,
**apply_last_callback** is going to execute just before we send the final
response.
It is a multipurpose solution, a user also can use it from view to modify
the response object at end of the chain
{{{
@last_modified(latest_entry, apply_last=True)
@never_cache(apply_last=True)
@cache_page(3600)
def tem_view(request):
r = random.randint(1000, 9999)
return TemplateResponse(request, 'index.html', context=dict(value=r))
}}}
Please Let me Know, your views on this.
--
Ticket URL: <https://code.djangoproject.com/ticket/33588#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018650dea176-9a63b048-943c-4dc6-a0ed-1fdc50ec82a4-000000%40eu-central-1.amazonses.com.
