Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Existing behavior
The existing
simplecache
code does not include URL query string parameters in the cache key. This means that a GET request to the same URL with different query strings will return the same cached response.Issue
I have a video management server project where an endpoint returns an image, and the user can set the desired size with the URL query (e.g.
http://my_server/image_endpoint?width=480
). The remote cameras are connected via a slow metered connection, so I want to cache responses.However, if the user requests:
http://my_server/image_endpoint?width=480
http://my_server/image_endpoint?width=1920
,The 480px-wide image, cached for (1), is used as the cached response for (2), even though the user requested a 1920px-wide image.
Why not have the user provide a JSON payload with the desired image width instead of a URL parameter?
The customer wants to easily access images by pasting a URL into their browser. They do not want to construct HTTP requests with payloads with CURL or similar tools.
Suggested change in this MR
This MR adds a
ConsiderUrlQuery
flag. In its defaultfalse
state, existing behavior is preserved. If set totrue
, query parameters will be used in the cache key.Perhaps in the future, it could be useful to provide a list of query string parameters to include/exclude from the cache key. However, I am new to this repo's conventions and would like to ensure I understand the maintainer's preferences before adding more changes.