docs: Update HTTP cache references to RFC 9111 compliant implementation #3608
+9
−6
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.
This PR updates the documentation and example code to recommend
bartventer/httpcache
instead ofgregjones/httpcache
.bartventer/httpcache
is actively maintained and complies with RFC 9111 HTTP Caching.Motivation
bartventer/httpcache
implements RFC 9111 §4.1, including proper normalization of Vary headers and URIs when generating cache keys. This covers recommended normalization steps from RFC 7230 §2.7.3 and RFC 3986 §6. In contrast,gregjones/httpcache
uses(*url.URL).String()
as the cache key, which means it cannot support Vary-based caching and may produce unpredictable caching behaviour for requests that differ by query parameters, fragments, or other URI components.Additionally,
bartventer/httpcache
also:stale-while-revalidate
and theimmutable
cache-control extension.200
,203
,301
,304
,308
,404
,405
,410
,414
, and501
.X-Httpcache-Status
) for easier debugging and monitoring (HIT
,MISS
,STALE
,REVALIDATED
,BYPASS
).X-From-Cache
header for drop-in replacement.