when request is present, cache is disabled
schwannden opened this issue · 2 comments
Due to this line:
fastapi-cache/fastapi_cache/decorator.py
Line 128 in 8f0920d
When request is present, cache is disabled. Why do we do so? Isn't it quite normal if user want to customize key builder that takes in request object?
I can create a pr to fix this but just wondering why the design is so in the first place.
because @cache
can be apply for general function or method, like this:
when request is present, it will run there
fastapi-cache/fastapi_cache/decorator.py
Line 151 in 8f0920d
Pretty sure this was never an issue, but perhaps the refactoring work done in #139 makes it easier to understand when caching is applied and when not.
The request and response objects remain optional, meaning the original methods can be called directly without having to pass in a request or response object unless those methods specifically need them.
This is what the decorator does; wherever these steps reference the request or response, those parts are skipped if no request or response is present:
- if caching is explicitly disabled (when
FastAPI.get_enabled()
returnsFalse
, or the request has aCache-Control
header with the valueno-store
orno-cache
, or the request method is notGET
), then the method is called directly and the result is returned. - if there was no cached value, the method is called and the result stored in the backend. Headers are added to the response to provide information that a browser can use to help avoid even sending a response body when the data is still cached later on.
- otherwise, the cached data is used to produce the returned value. If the browser sent a
If-None-Match
header with a value that matches the cached result ETag, a 304 Not Modified response is returned with no body, saving bandwidth.
Specifically, this is what this looks like:
fastapi-cache/fastapi_cache/decorator.py
Lines 135 to 207 in 4c4a7d6