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.
* Several protocol recommendations related to Cache-Control header composition no longer mentioned by RFC 7234 have been removed
* Cleanup of header constants
Implemented an enhancement to add a heuristic expiration warning to cached responses when the freshness lifetime and current age are both greater than one day. This warning, indicated by the '113' code, helps in identifying potential staleness in cached data and aligns with the HTTP caching specifications.
This commit refactors the CacheControl parsing logic to handle multiple "Cache-Control" headers. The previous implementation treated each header independently, returning an array of CacheControl objects. This caused issues when headers had directives that should be combined into a single CacheControl object.
The updated implementation combines all directives from all headers into a single CacheControl object, ensuring accurate representation of the caching directives.
This commit enhances the handling of the "no-cache" directive when used with specified header fields. The changes include:
* Updated the caching module to correctly identify and handle "no-cache" directives with specific header fields. This was done by modifying the `responseContainsNoCacheDirective` method.
* Modified the `handleCacheHit` method to ensure that a cached entry is revalidated with the origin server when a "no-cache" directive with specific header fields is present in the response.
* Ensured that the rest of the response is still cacheable when the specified header fields are present, as long as the response complies with other caching requirements.
.
This commit adds the Last-Modified header to the 304 Not Modified response when the ETag header is not present in the cache entry. This aligns the behavior with the recommendations in RFC 7232 and helps clients that rely on the Last-Modified header for cache updates when
The stale-if-error Cache-Control directive is used to indicate that a cached response can be used to satisfy a request even when an error occurs, as long as the response is still fresh or within the specified staleness limit. However, in the current implementation, this directive is only applied to cache entries that are revalidatable, meaning they have an ETag or Last-Modified header and can be refreshed with a conditional request.
This commit extends the stale-if-error directive to apply to any stale cache entry, whether revalidatable or not. This ensures that clients will continue to receive a cached response even if the original request resulted in an error, and helps to reduce the load on origin servers.
This commit adds several new constant values to the HttpByteArrayCacheEntrySerializer class to manage cache entry headers. The HttpByteArrayCacheEntrySerializer class was also updated with a new constructor to set the buffer size and a new method to serialize HTTP cache storage entry objects. Additionally, the code was refactored to enhance performance and remove unnecessary variables.
Previously, the same Cache-Control header was being parsed twice, once by isExplicitlyNonCacheable and again by calculateFreshnessLifetime. The parsing code was extracted from calculateFreshnessLifetime and enhanced to include the main cache control directive that isExplicitlyNonCacheable could use to make its decision. This improves the efficiency and accuracy of the caching logic.
Update ResponseCachingPolicy to allow caching of responses to POST requests under certain circumstances, as specified in RFC 2616 and explained in more detail in draft-ietf-httpbis-p2-semantics-20#section-2.3.4. This change extends the cacheability of responses beyond GET and HEAD methods, improving the cache's efficiency and reducing network traffic.
Previously, the getCacheEntry method was not correctly selecting the matching variant for a given request, which led to incorrect behavior when serving cached responses.
This commit improves the method's logic to correctly identify the cache entry using the request's cache key, and then select the variant with the matching ETag value. If no matching variant is found, the cache entry is considered stale and a new response is fetched from the origin server. The fix includes a new test case to ensure the correct behavior of the method in this scenario
- Super interface already implements FutureCallback
- No need to override methods to only call super
- Add missing Javadoc tag
- Access static field directly
* Add final to variable
* Unnecessary semicolon
* Use Standard Charset object
* Unnecessary conversion to String
* Simplifiable conditional expression
* Replace 'Arrays.asList()' with Collections.singletonList
* Redundant local variable. Simplify
I observed the following problem: `Transfer-Encoding` and
`Content-Length` headers should be mutually exclusive and because I use
chunked transfer, the `Transfer-Encoding` header is set in the response
while the `Content-Length` header is not. In case of a 304 during a
revalidation, the header contains Content-Length=0. Probably a proxy is
responsible for this, just like the comment "Some well-known proxies
respond with Content-Length=0, when returning 304" in the method
CachedHttpResponseGenerator::addMissingContentLengthHeader is saying. In
CacheEntryUpdater::mergeHeaders the Content-Length=0 is merged into the
cached entry, but the cached entry contains also a `Transfer-Encoding`
header, so in the cached entry these headers aren't mutually exclusive
anymore. Because of the `Transfer-Encoding` header the method
CachedHttpResponseGenerator::addMissingContentLengthHeader isn't fixing
the `Content-Length` header and Content-Length=0 causes returning null
instead of the cached content. IMHO the `Content-Length` header should
not be merged into the cached response in case of a 304, at least if the
cached entry contains a `Transfer-Encoding` header.
Note that this may change the origin of logging when classes
have been subclassed, as the logger origin will use the class
name that defined the logger where previously the subclass type
would be used. In scenarios where external libraries subclass
httpclient utilities this allows httpclient logging to maintain
the `org.apache.hc` prefix instead of inheriting arbitrary
subclass names.
Using some logging frameworks this may result in reduced churn
when httpclient components are created (new connections, for example)
because loggers are looked up once per class.
Oleg Kalnichevski
Arturo Bernal
Gary Gregory
Michael Lee
MartinWitt
Gary Gregory
jkmcl
j3graham
Hervé Boutemy
Michael Osipov
dirkhenselin
Carter Kozak
Niels Basjes
Carter Kozak