* Updates the RequestIfRange class to utilize DateUtils for parsing standard HTTP dates.
* Optimize time difference check in RequestIfRange with Instant API.
* 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
- Add RequestTraceInterceptor class to handle HTTP TRACE requests in compliance with RFC 7231, Section 4.3.8.
- Throw ProtocolException for sensitive headers like 'Authorization' and 'Cookie' in TRACE requests.
- Throw ProtocolException if TRACE request contains a body.
- Ensure the presence of 'Range' header when 'If-Range' is specified.
- Enforce strong validator requirements when 'If-Range' is paired with a Date.
- Exit processing early if 'Last-Modified' header is missing, ensuring strong validation adherence.
* 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
- This adheres to RFC 9110, which states: "There is no default port; a client MUST send the port number even if the CONNECT request is based on a URI reference that contains an authority component with an elided port.
- 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
This commit enhances the getFreshnessLifetime() method in the CacheValidityPolicy class to better comply with RFC 9111 4.2.1. The method now accounts for a negative Duration between the Date and Expires header fields.
1. Added support for HTTP 412 (Precondition Failed) status code. This status code is returned when one or more conditions given in the request header fields evaluated to false when tested on the server.
2. Ensured all instances of `If-Match` and `If-None-Match` headers are considered as required by the specification.
3. Added handling for cases where a weak ETag is used with a range request.
Oleg Kalnichevski
Arturo Bernal
Arturo Bernal