Copilot commented on code in PR #13611:
URL: https://github.com/apache/trafficserver/pull/13611#discussion_r3960333338
##########
src/proxy/http/HttpTransact.cc:
##########
@@ -2582,6 +2582,22 @@ HttpTransact::issue_revalidate(State *s)
return;
}
+ // An object found under the 9.2 key cannot be revalidated conditionally. The
+ // write that would apply a 304 is a create on the canonical key rather than
+ // an update of the legacy vector, so the cache discards it. Ask for the full
+ // response instead, which migrates the object to the canonical key.
+ if (s->state_machine != nullptr &&
should_use_compatibility_cache_key(s->state_machine->compatibility_cache_lookup))
{
+ // build_request() already strips the client's conditionals for a request
it
+ // expects to cache, but keeps them when the request does not look
cacheable
+ // or when cache_when_to_revalidate is 4. Either way the origin could
answer
+ // 304, so drop them here too. The client still gets its 304: a conditional
+ // client request is matched against the full response in
+ // handle_cache_operation_on_forward_server_response().
+ TxnDbg(dbg_ctl_http_trans, "compatibility key hit, revalidating without
conditional headers");
+
HttpTransactHeaders::remove_conditional_headers(&s->hdr_info.server_request);
+ return;
+ }
Review Comment:
`should_use_compatibility_cache_key()` is defined in `HttpSM.h`, but it’s
now used from `HttpTransact.cc`. That creates a cross-layer dependency
(transaction logic depending on SM header utilities) and can invite circular
include pressure over time. Consider relocating this helper (and/or the enum
predicate) to a more neutral header (e.g., `HttpTransact.h` or a small shared
cache-compat header) so `HttpTransact` doesn’t need to conceptually depend on
`HttpSM`.
##########
doc/admin-guide/files/records.yaml.en.rst:
##########
@@ -2800,6 +2800,24 @@ Cache Control
You can monitor this metric and know when its safe to turn this feature off
as the cache wraps around.
+ Two costs come with enabling this. Every cache miss performs a second
+ lookup, so a tier with a low hit ratio roughly doubles its cache lookup
+ load for the duration. And an object found under the previous key is
+ revalidated *without* conditional headers, because a ``304`` cannot be
+ applied to it: the write that would carry the update is a create under the
+ new key rather than an update of the old one. The origin therefore returns
+ the full response, which is stored under the new key. The copy under the
+ previous key is left in place to age out on its own, since nothing reports
+ that the new object reached disk; it stops being read as soon as the new key
+ resolves, so both keys briefly hold the object. Each object pays this once,
+ but on a large cache the aggregate is a bandwidth event worth sizing before
+ enabling the setting in production.
Review Comment:
The new behavior explicitly skips the compatibility lookup when the URL path
contains a `;` (keys converge), so it’s not accurate to say *every* cache miss
performs a second lookup. Please soften/qualify this claim (e.g., only misses
where the canonical and 9.2 keys differ / where the path has no `;`) to match
the documented exception added later in the same section.
##########
include/proxy/http/HttpSM.h:
##########
@@ -182,6 +179,22 @@ enum class CompatibilityCacheLookup {
COMPAT_CACHE_LAST,
};
+/// Whether this lookup addresses the cache with the previous (9.2) key.
+inline bool
+should_use_compatibility_cache_key(CompatibilityCacheLookup lookup)
+{
+ return lookup == CompatibilityCacheLookup::COMPAT_CACHE_LOOKUP_92;
+}
+
+/// The object info to hand to a cache write, which a compatibility read must
not
+/// carry: it belongs to the legacy key and would turn the write into an update
+/// of a vector the canonical key does not have.
+inline CacheHTTPInfo *
+cache_write_info_for_lookup(CompatibilityCacheLookup lookup, CacheHTTPInfo
*object_read_info)
+{
+ return should_use_compatibility_cache_key(lookup) ? nullptr :
object_read_info;
+}
Review Comment:
These new helpers are introduced in the global namespace in a widely
included header, which increases the chance of name collisions and makes
ownership less obvious. Consider moving them into `HttpSM` as `static` helpers,
or into a small dedicated namespace (e.g., `http::cache`) to reduce global
symbol pollution while keeping call sites readable.
##########
src/proxy/http/HttpSM.cc:
##########
@@ -5279,6 +5283,18 @@ HttpSM::do_range_setup_if_necessary()
}
}
+// The URL this transaction looks up in the cache. A redirect follow looks up
the
+// redirected URL rather than the original, unless the transaction is
configured
+// to keep the original cache key.
+URL *
+HttpSM::cache_lookup_url()
+{
+ if (t_state.redirect_info.redirect_in_process &&
!t_state.txn_conf->redirect_use_orig_cache_key) {
+ return t_state.hdr_info.client_request.url_get();
+ }
+ return t_state.cache_info.lookup_url;
+}
Review Comment:
The comment is currently hard to reconcile with the returned fields
(`client_request.url_get()` vs `cache_info.lookup_url`) because it doesn’t
explain which one represents the redirected URL vs the original in this state
machine phase. Please clarify the comment (or rename the helper/locals) to
explicitly state which member holds the redirect-follow URL and when, so future
changes don’t accidentally reverse the intended behavior.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
