Copilot commented on code in PR #12679:
URL: https://github.com/apache/trafficserver/pull/12679#discussion_r2776901887
##########
src/proxy/http/HttpConfig.cc:
##########
@@ -694,6 +694,40 @@ const MgmtConverter HttpStatusCodeList::Conv{
}};
// clang-format on
+/////////////////////////////////////////////////////////////
+//
+// TargetedCacheControlHeaders implementation
+//
+/////////////////////////////////////////////////////////////
+
+void
+TargetedCacheControlHeaders::parse(std::string_view src)
+{
+ count = 0;
+ swoc::TextView config_view{src};
+
+ while (config_view && count < MAX_HEADERS) {
+ swoc::TextView header_name =
config_view.take_prefix_at(',').trim_if(&isspace);
+ if (!header_name.empty()) {
+ headers[count++] = std::string_view{header_name.data(),
header_name.size()};
+ }
+ }
+}
+
+// clang-format off
+const MgmtConverter TargetedCacheControlHeaders::Conv{
+ [](const void *data) -> std::string_view {
+ const TargetedCacheControlHeaders *hdrs = static_cast<const
TargetedCacheControlHeaders *>(data);
+ return hdrs->conf_value ? hdrs->conf_value : "";
+ },
+ [](void *data, std::string_view src) -> void {
+ TargetedCacheControlHeaders *hdrs =
static_cast<TargetedCacheControlHeaders *>(data);
+ // The string_views in headers[] point into conf_value, so conf_value must
+ // remain stable for the lifetime of the parsed headers.
+ hdrs->parse(src);
Review Comment:
The `TargetedCacheControlHeaders::Conv` store lambda comments that
`headers[]` points into `conf_value` and therefore requires `conf_value` to
remain stable, but the implementation only calls `parse(src)` and never updates
`conf_value`. This is misleading as written and also makes `headers[]` point
into the caller-provided `src` buffer, whose lifetime may not be stable if this
converter is ever used directly. Consider either updating `conf_value`
consistently (and parsing from it) or adjusting the comment/implementation so
the referenced backing storage and its required lifetime are unambiguous.
```suggestion
hdrs->conf_value = src.data();
hdrs->parse(std::string_view{hdrs->conf_value, src.size()});
```
##########
src/proxy/hdrs/MIME.cc:
##########
@@ -3725,13 +3726,26 @@ MIMEHdrImpl::recompute_cooked_stuff(MIMEField
*changing_field_or_null)
mime_hdr_cooked_stuff_init(this, changing_field_or_null);
- //////////////////////////////////////////////////
- // (1) cook the Cache-Control header if present //
- //////////////////////////////////////////////////
+ /////////////////////////////////////////////////////////////////////////////
+ // (1) cook the Cache-Control header (or targeted variant) if present //
+ /////////////////////////////////////////////////////////////////////////////
// to be safe, recompute unless you know this call is for other cooked field
if ((changing_field_or_null == nullptr) ||
(changing_field_or_null->m_wks_idx != MIME_WKSIDX_PRAGMA)) {
- field = mime_hdr_field_find(this,
static_cast<std::string_view>(MIME_FIELD_CACHE_CONTROL));
+ field = nullptr;
+
+ // Check for targeted cache control headers first (in priority order).
+ for (size_t i = 0; i < targeted_headers_count; ++i) {
+ field = mime_hdr_field_find(this, targeted_headers[i]);
+ if (field) {
+ break;
+ }
+ }
+
+ // If no targeted header was found, fall back to standard Cache-Control.
+ if (!field) {
Review Comment:
`recompute_cooked_stuff` now selects a targeted cache-control header based
on the `targeted_headers` parameters, but most existing callers (including the
automatic recompute paths triggered by header field mutations) will use the
defaults and therefore ignore targeted headers. This means any later
modification to `Cache-Control` / targeted headers can recook using only the
standard header and override the targeted behavior. Consider making
targeted-header selection part of the header object’s state (or otherwise
ensuring all recook call sites that can run before cache decisions provide the
transaction’s targeted header list).
```suggestion
// If no targeted header was found, fall back to standard Cache-Control
// only when no targeted headers were requested.
if (!field && (targeted_headers_count == 0 || targeted_headers ==
nullptr)) {
```
##########
src/proxy/http/HttpSM.cc:
##########
@@ -2100,14 +2100,18 @@ HttpSM::state_read_server_response_header(int event,
void *data)
}
// fallthrough
- case ParseResult::DONE:
-
+ case ParseResult::DONE: {
if (!t_state.hdr_info.server_response.check_hdr_implements()) {
t_state.http_return_code = HTTPStatus::BAD_GATEWAY;
call_transact_and_set_next_state(HttpTransact::BadRequest);
break;
}
+ // Recompute cooked cache control with targeted headers.
+ t_state.hdr_info.server_response.m_mime->recompute_cooked_stuff(nullptr,
+
t_state.txn_conf->targeted_cache_control_headers.get_headers(),
+
t_state.txn_conf->targeted_cache_control_headers.get_count());
+
Review Comment:
The targeted Cache-Control recompute happens before `do_api_callout()` for
`API_READ_RESPONSE_HDR`. If a plugin (e.g. header_rewrite) modifies
`Cache-Control` / targeted headers during that hook, the header mutation paths
will call `recompute_cooked_stuff(field)` without the targeted header list,
which can revert the cooked cache-control mask back to standard `Cache-Control`
semantics for later caching decisions. Consider recomputing with the targeted
header list after response-header hooks complete (or otherwise ensuring any
subsequent recompute uses the same targeted header list) so plugin-driven
header changes are reflected correctly.
--
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]
