[typescript-axios] Conditionally set user-agent

[DavidWittman]

The change in #20067 has caused some issues with clients which run in a Browser. This commit replaces that change, leaving the default User-Agent for axios unmodified, and only sets the User-Agent if the http-user-agent parameter is provided during generation time.

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in Git BASH)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@macjohnny

[macjohnny]

thanks for the fix!

[macjohnny]

cc
TypeScript | @TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @topce (2018/10) @akehir (2019/07) @petejohansonxo (2019/11) @amakhrov (2020/02) @davidgamero (2022/03) @mkusaka (2022/04) @joscha (2024/10)

[ckoegel]

I don't think this was the correct solution to the problem here. This PR removes the concept of a 'default' User-Agent header. The usage of the --http-user-agent flag (httpUserAgent config option) should be supported, which this PR does, but per the generate usage docs, this header should default to OpenAPI-Generator/{packageVersion}/{language}, which it now no longer does. I think the issue with using this in a browser may be related to this axios issue, which has been known about for a while now.

That issue doesn't seem to have much traction behind it, so we may need to implement a workaround, but I do think we should still attempt to give this generator a default header so it behaves like the others. Is there a different javascript/typescript generator that might have an example of some logic to not set this header if chrome/safari is detected?

[macjohnny]

@ckoegel but the user agent can just be set by the user of the generated code or at code generation with the flag, right?

[ckoegel]

Yes, but there is no default value any more, it was my understanding that the SDK should set that user agent header automatically, and then it can be changed either in the generated code or with this flag, is that not the case?

[macjohnny]

i think its safer without a default value, especially for frontend clients

[ckoegel]

would a valid solution for both front and backend clients be to include the changes in #20067 alongside #20611 ? I think this would solve the chrome issue while still allowing for a default value for backend clients

[macjohnny]

i think its better to keep the template code simple and have the consumers provide a user agent string via the param instead of setting skipDefaultUserAgent=false, since the consumer would need to add some extra config either way

[ckoegel]

I think the code will be simple regardless, #20611 adds 2 lines to the template file, and #20067 was already accepted. If we allow for both, backend client users can leave the config unchanged to get the default header, or override the default by setting httpUserAgent. Frontend users can use skipDefaultUserAgent to avoid the console errors.

This obviously isn't true for all users, but anyone wanting the user agent header to stay consistent with the package version would need to manually create the user agent header string based on the current package version, and then pass that in as a cli argument or update the config file each time the client is generated. This isn't as desirable as just updating one argument statically, in the case of a frontend user needing to add the skipDefaultUserAgent flag once.

IMO, the root of this issue is caused by an axios bug, and if that bug gets fixed, I don't think this generator should behave differently because it once existed.

[ckoegel]

@macjohnny Is this worth investigating? I'm happy to open a PR with the changes I'm suggesting so it can be tested.

[macjohnny]

not sure if its just an axios bug or would apply to browser clients in general. i still think at least for frontend clients, the default should be no user agent set. if its important for backend clients to set a user agent, they can do so with the parameter.

@joscha whats your opinion?

[joscha]

@joscha whats your opinion?

I agree with @ckoegel to set a default header. It will help developers of APIs to find out a culprit if issues happen in the way requests are made. Especially in regards to different versions. If someone wants to hide and/or adapt the user agent, they can override it and/or empty it. I believe the default should follow OpenAPI-Generator/{packageVersion}/{language}.

[macjohnny]

@ckoegel can we make a distinction between FE and BE clients, such that for FE clients by default the user agent will not be set?

[joscha]

@ckoegel can we make a distinction between FE and BE clients, such that for FE clients by default the user agent will not be set?

You mean when a client is used within a browser environment by a user or based on the language?
If on language, then I don't think that makes sense.
If in a browser, then possibly we could also forward the one from the browser it's running in, but for the person owning the endpoint it would make most sense to distinguish based on code running (ie what version of the generator was used to produce the code that makes the request), neither the environment it runs in (browser, node, bun, Deno) nor the language (JS, TS) should matter?
Can you explain your thoughts/intent about this approach a bit more, please?

[macjohnny]

ok so what i just tried is

fetch('https://www.wikipedia.org', {headers: {'User-agent': 'my-custom-agent'}}).then(res => console.log(res));

in chrome, and that doesn't give me warnings, it just ignores the user-agent header and overrides it with the one set by chrome.
so if its really just about the axios bug, can we find a way to just avoid setting it in Axios if in browser?

[ckoegel]

@macjohnny @joscha Let me know if there's an action item that comes from this, I'd be happy to implement/contribute!
I'm also happy to try to get some traction going again on that axios issue if we think that could be a solution