[
https://issues.apache.org/jira/browse/HTTPCLIENT-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17924002#comment-17924002
]
ASF subversion and git services commented on HTTPCLIENT-2354:
-------------------------------------------------------------
Commit 8b1ee82bfd8d377a3a59c066946ea248e12cd720 in httpcomponents-client's
branch refs/heads/dependabot/maven/testcontainers.version-1.20.4 from Arturo
Bernal
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=8b1ee82bf ]
Fix HTTPCLIENT-2354 by updating ResponseCachingPolicy to allow caching of
responses with "must-revalidate, max-age=0" in shared caches with Authorization
headers. The change aligns with RFC 9111 Section 5.2.2.2, ensuring responses
with "must-revalidate," "s-maxage," or "public" directives are cacheable. This
addresses cases where responses with Authorization headers were unnecessarily
excluded from caching. (#609)
> ResponseCachingPolicy::isExplicitlyCacheable does not account for
> "must-revalidate"
> -----------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-2354
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2354
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Affects Versions: 5.4.1
> Reporter: Skylar Sutton
> Priority: Minor
> Fix For: 5.4.2, 5.5-alpha1
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Using httpclient5-cache:5.4.1, backed by an EH Cache with the following
> config:
> * maxCacheEntries: Integer.MAX
> * maxObjectSize: Integer.MAX
> * sharedCache: true
> * setNeverCacheHTTP10ResponsesWithQueryString: false
> * setNeverCacheHTTP11ResponsesWithQueryString: false
> Execute a call against a resource with a query string (ex: "/foo?q=bar")
> which returns the following CacheControl:
> {code:java}
> Cache-Control: "must-revalidate, max-age=0" {code}
> The Apache Client will fail to cache the resource, specifically because of
> this check in {_}ResponseCachingPolicy::isResponseCachable{_}:
> {code:java}
> if (!this.neverCache1_1ResponsesWithQueryString &&
> !this.isExplicitlyCacheable(cacheControl, response)) {
> LOG.debug("Response is not cacheable as it is missing explicit caching
> headers");
> return false;
> } {code}
> More specifically, _ResponseCachingPolicy::isExplicitlyCachable_ does not
> contain any logic to handle the "must-revalidate" directive.
> Per documentation, "public" is not required if "must-revalidate" is provided.
> * [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control]
> ** *??"... If a request doesn't have an {{Authorization}} header, or you are
> already using {{s-maxage}} or {{must-revalidate}} in the response, then you
> don't need to use {{{}public ...{}}}"??*
> * [https://www.rfc-editor.org/rfc/rfc9111.html#name-must-revalidate]
> ** _*"The must-revalidate directive also permits a shared cache to reuse a
> response to a request containing an Authorization header field ([Section
> 11.6.2|https://www.rfc-editor.org/rfc/rfc9110#section-11.6.2] of
> [[HTTP|https://www.rfc-editor.org/rfc/rfc9111.html#HTTP]]), subject to the
> above requirement on revalidation ([Section
> 3.5|https://www.rfc-editor.org/rfc/rfc9111.html#caching.authenticated.responses])."*_
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
