Skip to content

stale_response: handle TS API failures instead of ignoring them - #13592

Draft
bryancall wants to merge 1 commit into
apache:masterfrom
bryancall:coverity-stale-response-retvals
Draft

stale_response: handle TS API failures instead of ignoring them#13592
bryancall wants to merge 1 commit into
apache:masterfrom
bryancall:coverity-stale-response-retvals

Conversation

@bryancall

Copy link
Copy Markdown
Contributor

Several call sites in the stale_response plugin discarded a TSReturnCode and then used an output parameter that the failing call never wrote.

The bug

TSHttpHdrUrlGet returns TS_ERROR without touching *locp when the header is not a request. The plugin did this in three functions:

TSMLoc url_loc;                                        // uninitialized
TSHttpHdrUrlGet(hdr_url_buf, hdr_url_loc, &url_loc);   // may not write url_loc
reqUrl.populate(hdr_url_buf, url_loc);                 // stack garbage used as a TSMLoc

On the failure path url_loc keeps stack garbage and is passed to UrlComponents::populate(), then to TSUrlHttpQuerySet() or TSUrlParse(), and finally to TSHandleMLocRelease().

create_request_info() had the same shape with TSHttpTxnClientReqGet and TSHttpHdrClone. That one is worse: req_info comes from TSmalloc() and is not zeroed, so a garbage TSMLoc is stored in a structure that lives for the whole transaction and is later handed to TSMimeHdrFieldFind, TSHttpHdrPrint, and TSHandleMLocRelease.

strip_trailing_parameter() also set stripped = true before calling TSUrlHttpQuerySet() and ignored its result, so it reported success even when the URL was never rewritten.

What changed

Check these calls, log through the plugin's existing debug tags, and bail the way neighboring code in the same file already does (get_pristine_url() and intercept_check_request() were already checking the identical call). create_request_info() now returns nullptr on failure and its callers handle that. TSHttpTxnEffectiveUrlStringGet is null-checked before being passed to TSstrndup.

Known limitation, not addressed here

On a TSUrlParse failure in add_trailing_parameter(), the URL has already been cleared by the API before parsing begins, so that path continues with an emptied URL. This change makes the failure visible in the logs rather than silent, but does not repair the URL. Doing that properly means snapshotting the original and restoring it, which is a behavior change that belongs in its own patch.

Testing

The plugin builds clean. The changes were reviewed specifically for new leaks and double-releases on the added error paths.

Several call sites discarded a TSReturnCode and then used an output
parameter the failing call never wrote. TSHttpHdrUrlGet returns TS_ERROR
without touching *locp when the header is not a request, so an
uninitialized TSMLoc reached UrlComponents::populate(),
TSUrlHttpQuerySet() and TSHandleMLocRelease() in three functions.
create_request_info() had the same problem with TSHttpTxnClientReqGet
and TSHttpHdrClone, storing a garbage TSMLoc in a TSmalloc'd structure
that lives for the whole transaction.

Check these calls, log through the plugin's existing tags, and bail the
way neighboring code already does. create_request_info() now returns
nullptr on failure and its callers handle that. strip_trailing_parameter()
reports false when the query rewrite itself fails, rather than claiming
a strip that did not happen.

Note that on a TSUrlParse failure the URL has already been cleared by
the API before parsing begins, so that path still continues with an
emptied URL. This change makes that visible in the logs rather than
silent; repairing it needs a separate fix.
@bryancall bryancall self-assigned this Aug 27, 2026
@bryancall bryancall added this to the 11.0.0 milestone Aug 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant