Copilot commented on code in PR #13611:
URL: https://github.com/apache/trafficserver/pull/13611#discussion_r3958412025


##########
src/proxy/http/HttpTransact.cc:
##########
@@ -2582,6 +2582,15 @@ 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 && 
HttpSM::should_use_compatibility_cache_key(s->state_machine->compatibility_cache_lookup))
 {
+    TxnDbg(dbg_ctl_http_trans, "compatibility key hit, revalidating without 
conditional headers");

Review Comment:
   Returning early here prevents *adding* cache-derived conditional headers, 
but it does not actively remove preexisting conditional headers that may 
already be present on the outbound request (e.g., client-supplied If-None-Match 
/ If-Modified-Since forwarded upstream). In that case the origin can still 
respond 304 and the compatibility-key update path remains a no-op. Consider 
explicitly stripping all conditional request headers from the server/parent 
request when `compatibility_cache_lookup` is 9.2 (at least `If-None-Match` and 
`If-Modified-Since`, and ideally the full set of preconditions) before 
returning.



##########
include/proxy/http/HttpSM.h:
##########
@@ -344,6 +341,21 @@ class HttpSM : public Continuation, public 
PluginUserArgs<TS_USER_ARGS_TXN>
   void           set_http_schedule(Continuation *);
   int            get_http_schedule(int event, void *data);
 
+  static bool
+  should_use_compatibility_cache_key(CompatibilityCacheLookup lookup)
+  {
+    return lookup == CompatibilityCacheLookup::COMPAT_CACHE_LOOKUP_92;
+  }
+
+  static CacheHTTPInfo *
+  cache_write_info_for_lookup(CompatibilityCacheLookup lookup, CacheHTTPInfo 
*object_read_info)
+  {
+    if (should_use_compatibility_cache_key(lookup)) {
+      return nullptr;
+    }
+    return object_read_info;
+  }

Review Comment:
   These helpers are now used by `HttpCacheSM` and `HttpTransact`, which 
introduces a tighter coupling on `HttpSM` than necessary (they’re essentially 
small policy/utility functions over an enum + pointer). To reduce cross-module 
dependency, consider moving them to a more neutral location (e.g., a small 
http-cache-key-compat utility header, or `HttpTransact.h` if that’s where the 
policy lives), or inline the simple enum comparison at call sites.



-- 
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]

Reply via email to