Keep a pg_net token when a request sets its own User-Agent

Open
  • Is something wrong?
#324 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
72/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
c, postgresql
Domain
backend, networking

Research direction

Start in init_curl_handle in src/core.c and review how caller headers and the default CURLOPT_USERAGENT are added. Then read the User-Agent cases in test/test_http_headers.py. Done means requests with a caller-supplied User-Agent send one header with the caller value first and the pg_net version token appended, while requests without one retain the existing default.

Written by the indexing model from the issue text.

Description

Follow-up to #322 / #323.

Since #323, a User-Agent set in headers replaces the default completely, so the request no longer says it came from pg_net:

select net.http_get(
  url := 'http://localhost:8080/headers',
  headers := '{"User-Agent": "my-app/1.0"}'
);

User-Agent: my-app/1.0

#323 was right to stop sending two User-Agent headers. This issue proposes keeping the single header but adding pg_net to the end of the caller's value, instead of dropping it.

Proposed behavior

A User-Agent may list several product tokens, most important first (RFC 9110 §10.1.5). pg_net could add its own token after the caller's:

User-Agent: my-app/1.0 pg_net/0.20.4
  • Requests without a User-Agent keep sending User-Agent: pg_net/<version>, as they do today.
  • There is still exactly one User-Agent header, so #322 stays fixed.
  • The caller's token stays first, so servers that look at the first product still see the caller's app.
Why

Operators who receive pg_net traffic (API providers, webhook receivers, abuse and security teams) use the User-Agent to tell which client sent a request. When requests carry no pg_net token, they can't tell pg_net traffic apart from other clients, for example when triaging unexpected or abusive outbound requests from a database. Clients such as the AWS CLI and SDKs (aws-cli/2.x Python/3.x ...) and browsers use the same multi-token convention.

Possible implementation

In init_curl_handle (src/core.c), while building the request header list, find a caller-supplied User-Agent (any letter case) and rewrite it as <caller value> pg_net/<EXTVERSION>. If there isn't one, keep the CURLOPT_USERAGENT default added in #323. The tests in test/test_http_headers.py would need to change to expect the appended token.

If a fully caller-controlled User-Agent is something users rely on, an opt-out setting could keep the #323 behaviour, but I'd suggest appending by default.

Dominant language
Python
Stars
376
Forks
44
Avg merge
5d 11h
Merged PRs (30d)
16

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from supabase/pg_net

All issues in supabase/pg_net

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.