* optimized parting of Via response header values in order to generate less intermediate garbage
* optimized Via message header generation
* moved Via request header generation to a cache request interceptor
* moved Via response header generation to a cache response interceptor
* HTTPCLIENT-2277: Deprecated 303 response caching switch as no longer required by RFC 9111
* Javadoc improvements (no functional changes)
* HTTPCLIENT-2277: Revision of HTTP cache protocol requirement and recommendation test cases:
* Removed links to RFC 2616
* Removed verbatim quotes from RFC 2616
* Removed obsolete test cases and test cases without result verification / assertions
* Removed test cases unrelated to HTTP caching
* Removed test cases without test result assertions
- Replaced `synchronized` blocks with `ReentrantLock` in `LeaseRequest` to better support virtual threads introduced in JDK 21.
- Ensured each `LeaseRequest` instance has its own unique lock for maintaining original synchronization semantics.
- Addressed potential performance and deadlock issues with virtual threads by using explicit lock primitives from `java.util.concurrent.locks`.
* request URI stored in cache is now normalized and is presently expected to be the same as the root key
* removed references to variant cache keys from the cache entry
* Variants in root entries are now represented as a set, not as a map
This commit adds the functionality to handle the 'immutable' directive in the Cache-Control header as per the RFC8246 specifications.
Key changes include:
- The 'immutable' directive is checked in the Cache-Control of an HTTP response, indicating that the origin server will not update the resource representation during the response's freshness lifetime.
- If the 'immutable' directive is present and the response is still fresh, the response is considered cacheable without further validation.
- Ignoring any arguments with the 'immutable' directive, as per RFC stipulations.
- Treating multiple instances of the 'immutable' directive as equivalent to one.
This commit introduces changes to handle the 'must-understand' directive in accordance with the updated HTTP cache-related RFC 9111. The logic ensures that the cache only stores responses with status codes it understands when the 'must-understand' directive is present.
This implementation adheres to the following RFC guidance:
- A cache that understands and conforms to the requirements of a response's status code may cache it when the 'must-understand' directive is present.
- If the 'no-store' directive is present along with the 'must-understand' directive, the cache can ignore the 'no-store' directive if it understands the status code's caching requirements.
* Cache entries now can be of two distinct types: root entries containing a map of known representation variants of the same resource and resource entries containing a resource potentially sharable by multiple resource entries. The same entry cannot have a variant map and a resource at the same time
* Cache entry factory class added to the public APIs
Oleg Kalnichevski
Arturo Bernal