Re: [Django] #33588: @never_cache and @cache_page decorators are applied out of order for TemplateResponse.

0 views
Skip to first unread message

Django

unread,
Sep 26, 2022, 4:43:56 PM9/26/22
to django-...@googlegroups.com
#33588: @never_cache and @cache_page decorators are applied out of order for
TemplateResponse.
-------------------------------------+-------------------------------------
Reporter: Jacek Wojna | Owner: Domen
| Blenkuš
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
-------------------------------------+-------------------------------------
Changes (by Domen Blenkuš):

* owner: nobody => Domen Blenkuš
* status: new => assigned


--
Ticket URL: <https://code.djangoproject.com/ticket/33588#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Feb 14, 2023, 1:32:14 AM2/14/23
to django-...@googlegroups.com
#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
-------------------------------------+-------------------------------------
Changes (by noneNote):

* owner: Domen Blenkuš => noneNote


--
Ticket URL: <https://code.djangoproject.com/ticket/33588#comment:4>

Django

unread,
Feb 14, 2023, 12:00:17 PM2/14/23
to django-...@googlegroups.com
#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>

Reply all
Reply to author
Forward
0 new messages