arturobernalg commented on code in PR #460:
URL:
https://github.com/apache/httpcomponents-client/pull/460#discussion_r1237638924
##########
httpclient5-cache/src/main/java/org/apache/hc/client5/http/impl/cache/CacheKeyGenerator.java:
##########
@@ -94,18 +96,67 @@ public String generateKey(final HttpHost host, final
HttpRequest request) {
}
}
- private String getFullHeaderValue(final Header[] headers) {
- if (headers == null) {
- return "";
+ /**
+ * Returns all variant names contained in {@literal VARY} headers of the
given message.
+ *
+ * @since 5.3
+ */
+ public static List<String> variantNames(final MessageHeaders message) {
+ if (message == null) {
+ return null;
+ }
+ if (!message.containsHeader(HttpHeaders.VARY)) {
Review Comment:
Could we possibly omit the check `if
(!message.containsHeader(HttpHeaders.VARY))`?
If I understand correctly, if there are no `VARY` headers present, the loop
`for (final Iterator<Header> it = message.headerIterator(HttpHeaders.VARY);
it.hasNext(); )` wouldn't iterate, making the explicit check redundant. Am I
missing something?"
##########
httpclient5-cache/src/main/java/org/apache/hc/client5/http/impl/cache/BasicHttpAsyncCache.java:
##########
@@ -90,11 +91,15 @@ public BasicHttpAsyncCache(final ResourceFactory
resourceFactory, final HttpAsyn
@Override
public String generateKey(final HttpHost host, final HttpRequest request,
final HttpCacheEntry cacheEntry) {
- if (cacheEntry == null) {
- return cacheKeyGenerator.generateKey(host, request);
- } else {
- return cacheKeyGenerator.generateKey(host, request, cacheEntry);
+ final String root = cacheKeyGenerator.generateKey(host, request);
Review Comment:
@ok2c
This looks duplicated in BasicHttpCache and BasicHttpAsyncCache,
- We could move the generateKey method to CacheKeyGenerator to centralize
the key generation logic, although this could increase coupling between
CacheKeyGenerator and HttpCacheEntry.
- Alternatively, we could introduce a common superclass for BasicHttpCache
and BasicHttpAsyncCache that contains the generateKey method. This approach
could be beneficial if there are more shared behaviors in these two classes,
but it might over-complicate the design if this is the only common method."
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
