Opened 63 minutes ago
#37428 assigned New feature
Add support for HTTP QUERY method to CacheMiddleware/@cache_page
| Reported by: | Jacob Walls | Owned by: | Participants on sibling ticket have right of first refusal |
|---|---|---|---|
| Component: | Core (Cache system) | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Jonathan Biemond, Michiel Beijen | Triage Stage: | Unreviewed |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Sibling ticket for #37232, which is already advanced on the new features board. This ticket is not open for assignment until the contributors who have already reviewed and participated on #37232 have had a chance to indicate interest.
#37232 left caching out of scope. We should consider adding support for caching HTTP QUERY methods to the cache middleware if we can answer these questions:
- Cache key: I presume we need to append a hash of the request body to the cache key, without parsing.
- Re-reading: what happens when a view calls
request.read()? This would causeRawPostDataExceptionwhen trying to read the raw body again to calculate the cache key afterward. (Calculating the key after the view could happen on cold-caches.) - Do we let
RequestDataTooBigemanate from the cache middleware instead of the view? This could catch someone who hasexcept RequestDataTooBigin adef post()decorated with@csrf_exemptthat they are converting todef query(). Or do we treat the over-limit case as "don't cache" and let the view run? One way or the other we might need a backward incompatible change notice.
Note:
See TracTickets
for help on using tickets.