HTTP cache support for the QUERY method (RFC 10008)#852
Conversation
|
@hunghhdev Awesome! Out of curiosity is this effort coordinated with the original author of #840 or is it purely coincidental? Please note there is #850 that still needs to land that improves the process of cache key generation. Overall looks very good. |
No, this PR was not coordinated, I just saw this. If you prefer this code instead, I can stop #846. |
@desiderantes This is the first time we, as a project, have multiple contributions of the same feature. I suggest we proceed with @hunghhdev contribution as it is almost complete and it is a first-time contribution. In the meantime, if you have time and inclination what also needs to be done is to extend |
|
@hunghhdev Very good. Please re-base off the latest master and update the cache key generation logic |
Rebased off the latest master |
…closed entity to be repeatable
ok2c
left a comment
There was a problem hiding this comment.
@hunghhdev Looks good. I will merge this change-set tomorrow if I hear no objections.
|
@hunghhdev Many thanks for this contribution! There is still one more thing that needs to be done: |
Thanks for merging! I'll take the HttpCacheEntry extension as a follow-up. @desiderantes hope you don't mind me picking this one up too |
* HTTP cache support for the QUERY method (RFC 10008) * Do not buffer QUERY request content larger than 25 KB; require the enclosed entity to be repeatable
Follow-up to #840. The caching layer can now store and serve responses to
QUERYrequests: cache keys incorporate a digest of the request content and content type, and both classic and async interceptors bufferQUERYbodies instead of bypassing the cache. Anything that cannot be buffered safely still falls back to direct execution.