NpgsqlRest

Appearance

Comments
AI-assisted, verified against source

Changelog v3.18.1 ​

Version 3.18.1 (2026-06-23) ​

Full Changelog

Patch release that makes all automatic (server-filled) parameters forward to proxy endpoints consistently, in the endpoint's native parameter shape.

What changed ​

When an endpoint is a proxy, the parameters that NpgsqlRest fills server-side are now forwarded to the upstream uniformly, regardless of source:

  • user claims (claim-mapped parameters),
  • IP address parameter,
  • HTTP Custom Type fields (the auto-filled responseBody / responseStatusCode / … on a routine with an HTTP Custom Type parameter),
  • resolved-parameter expressions (values looked up server-side via SQL).

All of them follow the same placement rule, which mirrors how the endpoint itself receives parameters — not the HTTP verb:

  • The parameter designated as the body parameter (@body_parameter_name) carries the raw request body.
  • Otherwise placement follows the endpoint's RequestParamType: QueryString → appended to the proxy query string; BodyJson → merged into the proxy JSON body (typed: numbers, booleans, embedded JSON, or strings), when the proxy method can carry a JSON body.

This is additive: the verbatim incoming request is still forwarded; the automatic parameters are added on top, so the upstream receives the same parameter set the routine would have.

Why ​

Previously the behavior was inconsistent: user-claim and IP parameters were always appended to the query string, HTTP Custom Type fields and resolved parameters were not forwarded at all, and a passthrough proxy discarded the auto-filled values entirely (the outbound HTTP Custom Type call fired but its result went nowhere). Now every automatic parameter behaves the same way.

Behavior change to note ​

User-claim and IP parameters now follow RequestParamType like every other automatic parameter. For a QueryString endpoint (the default for GET) they remain in the query string, exactly as before. For a BodyJson endpoint they are now merged into the JSON body rather than forced onto the query string. Method does not decide placement — RequestParamType does (a POST endpoint can use param_type query and its parameters then go to the query string).

Notes ​

  • Body merging applies only when the forwarded request carries a JSON content type; multipart and non-JSON bodies are forwarded verbatim.
  • Only the expanded per-field HTTP Custom Type parameters (DB-function shape) are forwarded; single-composite HTTP parameters (SQL-file shape) are not.

Tests ​

NpgsqlRestTests/ProxyTests/ProxyHttpTypeProbeTest.cs covers, via a WireMock proxy target that echoes the received URL / body: HTTP-type fields forwarded on the query (GET) and merged into the JSON body (POST, typed); placement following RequestParamType rather than the verb (a param_type query POST forwards to the query, not the body); and a resolved-parameter expression forwarded consistently. Existing user-claim / IP proxy tests continue to pass unchanged (GET → query string). Full suite green (2288).

Comments