Skip to content

provide user-agent customization? #2611

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jku opened this issue Apr 19, 2024 · 0 comments · Fixed by #2612
Closed

provide user-agent customization? #2611

jku opened this issue Apr 19, 2024 · 0 comments · Fixed by #2612

Comments

@jku
Copy link
Member

jku commented Apr 19, 2024

At some point we decided to not offer the ability to customize RequestsFetcher. The idea was that if someone wants to to customize, they can provide their own fetcher (possibly forking RequestsFetcher). In general this still seems reasonable.

There is one small customization I wish we had made easier: user-agent. It would be really useful for repository implementations to know which versions of which apps are connecting to the repository -- and it's a little much to expect apps to implement complete fetchers just to do that.

So maybe we should make extending the user-agent easier:

  • maybe add user-agent field to UpdaterConfig and forward the value to RequestsFetcher
  • alternatively make RequestsFetcher public and add an optional constructor argument user-agent

I think I like the first option more since it only increases the UpdaterConfig API (the downside is that only affects the default fetcher).

In both cases I think the argument should be added to the default user agent so you end up with MyApp/0.1 tuf/4.0.0 requests/1.2.3 in the repository logs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant