By design, if we get a query parameter on an https sink (cloud storage, webhook, etc.) that doesn't have significance in this context we transparently forward it. This can be confusing if the query param was meant to be significant. For example, 'webhook-https://localhost:3000?insecure_tsl_skip_verify=true' has a typo, "tsl" for "tls", that results in the param not having its intended effect, but no error.
We have at least two channels where we could warn on unrecognized params: pgnotice and error hints. We should do one or both of these:
NOTICE: Unrecognized param(s) insecure_tsl_skip_verify are interpreted as part of the URL.
retryable error: Post "https://localhost:3000?insecure_tsl_skip_verify=true": dial tcp [::1]:3000: connect: connection refused
HINT: The param(s) insecure_tsl_skip_verify were not recognized query params and were interpreted as part of the URL.
By design, if we get a query parameter on an https sink (cloud storage, webhook, etc.) that doesn't have significance in this context we transparently forward it. This can be confusing if the query param was meant to be significant. For example,
'webhook-https://localhost:3000?insecure_tsl_skip_verify=true'
has a typo, "tsl" for "tls", that results in the param not having its intended effect, but no error.We have at least two channels where we could warn on unrecognized params: pgnotice and error hints. We should do one or both of these:
Jira issue: CRDB-28645
Epic CRDB-28844