Safari User Agent error when sending messages

[dylanmoz]

Description

In safari, I get this error when sending a message: failed to load resource: request header field User-Agent is not allowed by Access-Control-Allow-Headers.

The user agent header is:

• In safari: ai-sdk/5.0.53 runtime/browser
• In chrome: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36

It seems in Chrome the browser overrides the user-agent header to what it wants it to be. However in Safari it lets it be custom, which is the value that vercel ai provides.

I'm curious if this is an issue with just my specific setup with my server/usage. I wonder if https://github.com/vercel/ai-chatbot will run into this issue when it upgrades ai. I think the version that introduced the issue is 5.0.43, but ai-chatbot uses an older version.

My workaround is to delete that header key. I'm already able to do this because I'm overriding the fetch call for useChat:

useChat({ transport: new DefaultChatTransport({ fetch: async (_, init) => { ... } }) })

AI SDK Version

'ai': 5.0.53 '@ai-sdk/react': 2.0.52

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[gr2m]

Is your server throwing the error? If so, I would add User-Agent to Access-Control-Allow-Headers

[oboard]

Same problem

[oboard]

I find the solution.

Safari has printed error

Failed to load resource: Request header field User-Agent is not allowed by Access-Control-Allow-Headers.

So we just need to append the "User-Agent" to server responses.

[dylanmoz]

Is your server throwing the error? If so, I would add User-Agent to Access-Control-Allow-Headers

No, the error is in Safari. But I think what you're saying is correct. The browser does a preflight request that gets the allowed headers. In the actual request, Chrome overrides the custom header in order for it to be safelisted despite the server not sending User-Agent as an allowed header. Safari doesn't override and uses the custom ai header which causes it to fail. I imagine adding User-Agent to Access-Control-Allow-Headers would fix the problem so that I don't have to delete the header, but I can't do that currently

[gr2m]

Is the problem with one of the AI Model providers or gateways? Or is it a server you deployed yourself? Very sorry for the friction this causes, but I'd rather not revert it, and also not add some kind of exception for Safari

[dylanmoz]

I believe its with our server, I guess that it doesn't send Access-Control-Allow-Headers user-agent for CORS preflight requests.

[nilveryboring]

i got the same issue

[gr2m]

@dylanmoz did you get it resolved?

@nilveryboring does your server handle the CORS preflight requests?

[dylanmoz]

@gr2m my solution was the one noted in the original post:

My workaround is to delete that header key. I'm already able to do this because I'm overriding the fetch call for useChat

I just imagine this will happen with other people, and it would be nice if there was either a way to avoid this problem altogether (remove the custom header value), or mention in the docs that the request ai makes will cause error X if your server does not have Y configured, so at least its documented and when a user searches the error the solution comes up