requestEventSource (internal/handlers/webhook.go) stores the method, headers, content type and body of a received request. It does not store the query string. A sender that carries information in URL parameters (a token, an event name, a signature) loses it on receipt: it is not in the event log, it is not archived, and an HTTP target never sees it. Nothing in the README says so.
Found by the 1.0 readiness review (#311); the audit at #303 noted it as a minor finding.
Definition of done
The raw query string of the receiving request is stored on the event (a new column on the per-webhook events table; pre-1.0, so no migration file), including for resubmitted copies.
The event log renders it with the request line, and the archive and log targets carry it, using the same masking the access log applies if any part of it is treated as sensitive there.
The README's Event data model section documents the field.
Whether an HTTP target receives it (appended to the target URL, or as a header) is an owner decision asked on this issue; until answered, storing and showing it is the whole unit and delivery is unchanged.
A test posts to /webhook/{uuid}?a=1&b=2 and asserts the stored and rendered value.
Model: fable-5-1
`requestEventSource` (`internal/handlers/webhook.go`) stores the method, headers, content type and body of a received request. It does not store the query string. A sender that carries information in URL parameters (a token, an event name, a signature) loses it on receipt: it is not in the event log, it is not archived, and an HTTP target never sees it. Nothing in the README says so.
Found by the 1.0 readiness review (https://git.eeqj.de/sneak/webhooker/issues/311); the audit at https://git.eeqj.de/sneak/webhooker/issues/303 noted it as a minor finding.
## Definition of done
- The raw query string of the receiving request is stored on the event (a new column on the per-webhook `events` table; pre-1.0, so no migration file), including for resubmitted copies.
- The event log renders it with the request line, and the archive and log targets carry it, using the same masking the access log applies if any part of it is treated as sensitive there.
- The README's Event data model section documents the field.
- Whether an HTTP target receives it (appended to the target URL, or as a header) is an owner decision asked on this issue; until answered, storing and showing it is the whole unit and delivery is unchanged.
- A test posts to `/webhook/{uuid}?a=1&b=2` and asserts the stored and rendered value.
Model: fable-5-1
clawbot
added this to the 1.0.0 milestone 2026-09-21 09:20:19 +02:00
Question for the owner: once the query string is stored, should an HTTP target receive it?
Append it to the target URL on delivery (recommended): the target gets the request the sender meant to make, which is what a proxy is for, and a target URL that already has a query string gets the two joined with &. Replay and resubmit carry it the same way.
Send it as a header only (for example X-Webhooker-Query): the target URL stays exactly what the operator configured, and a target that wants the parameters reads the header.
Store and show only: never forwarded.
The unit as filed stops at storing and rendering; delivery changes only on your answer here.
Model: fable-5-1
Question for the owner: once the query string is stored, should an HTTP target receive it?
- Append it to the target URL on delivery (recommended): the target gets the request the sender meant to make, which is what a proxy is for, and a target URL that already has a query string gets the two joined with `&`. Replay and resubmit carry it the same way.
- Send it as a header only (for example `X-Webhooker-Query`): the target URL stays exactly what the operator configured, and a target that wants the parameters reads the header.
- Store and show only: never forwarded.
The unit as filed stops at storing and rendering; delivery changes only on your answer here.
Model: fable-5-1
sneak
was assigned by clawbot2026-09-21 09:20:58 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
requestEventSource(internal/handlers/webhook.go) stores the method, headers, content type and body of a received request. It does not store the query string. A sender that carries information in URL parameters (a token, an event name, a signature) loses it on receipt: it is not in the event log, it is not archived, and an HTTP target never sees it. Nothing in the README says so.Found by the 1.0 readiness review (#311); the audit at #303 noted it as a minor finding.
Definition of done
eventstable; pre-1.0, so no migration file), including for resubmitted copies./webhook/{uuid}?a=1&b=2and asserts the stored and rendered value.Model: fable-5-1
Question for the owner: once the query string is stored, should an HTTP target receive it?
&. Replay and resubmit carry it the same way.X-Webhooker-Query): the target URL stays exactly what the operator configured, and a target that wants the parameters reads the header.The unit as filed stops at storing and rendering; delivery changes only on your answer here.
Model: fable-5-1