You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Fern documentation does not seem to provide any guidance on required CORS policies for clients such as the Typescript client, that may run in a browser based environment. This can lead to CORS issues for servers that do not have a permissive configuration.
Searching through the issues I found #3173 which seems to be an older (and no longer correct) contribution, but I haven't been able to find anything in the current version of the documentation.
Side-quest: are the custom headers even necessary?
It seems there are three headers sent by Fern when making requests:
x-fern-language
x-fern-runtime
x-fern-runtime-version
Non-standard headers do pose a problem with most vanilla CORS configurations, and could potentially pose a problem with HTTP proxies as well. Common HTTP guidance is to avoid non-standard headers unless absolutely necessary.
For a general purpose product like Fern, it would make sense to me at least to try and avoid using custom headers. Given @dannysheridan's commentary in #3453, it seems this is really mostly used to identify the user agent, so perhaps using the more standard user-agent would be less invasive, and compatible with CORS out-of-the-box to boot.
It would afford adding all those relevant bits, including some (optional and configurable) <comments>. Ideally the user agent string would be wholly configurable during SDK generation, but if not setting it to something reasonable like the above probably wouldn't hurt. It'd make for reasonable logs too I bet.
The text was updated successfully, but these errors were encountered:
What can be improved
The Fern documentation does not seem to provide any guidance on required CORS policies for clients such as the Typescript client, that may run in a browser based environment. This can lead to CORS issues for servers that do not have a permissive configuration.
Searching through the issues I found #3173 which seems to be an older (and no longer correct) contribution, but I haven't been able to find anything in the current version of the documentation.
Side-quest: are the custom headers even necessary?
It seems there are three headers sent by Fern when making requests:
x-fern-language
x-fern-runtime
x-fern-runtime-version
Non-standard headers do pose a problem with most vanilla CORS configurations, and could potentially pose a problem with HTTP proxies as well. Common HTTP guidance is to avoid non-standard headers unless absolutely necessary.
For a general purpose product like Fern, it would make sense to me at least to try and avoid using custom headers. Given @dannysheridan's commentary in #3453, it seems this is really mostly used to identify the user agent, so perhaps using the more standard
user-agent
would be less invasive, and compatible with CORS out-of-the-box to boot.Suggested format:
User-Agent: Fern <runtime>/<runtime-version> (<language>) <comments>
It would afford adding all those relevant bits, including some (optional and configurable)
<comments>
. Ideally the user agent string would be wholly configurable during SDK generation, but if not setting it to something reasonable like the above probably wouldn't hurt. It'd make for reasonable logs too I bet.The text was updated successfully, but these errors were encountered: