`createConnectTransport` replacing `user-agent` header on Safari and Firefox, but not chrome

[Greg McKelvey]

Describe the bug

createConnectTransport replacing user-agent header on Safari and Firefox, but not chrome.
Chrome has a normal looking user agent, but Safari and Firefox are getting: user-agent: connect-es/1.1.2

Environment (please complete the following information):

• @connectrpc/connect-web version: 1.1.2
• @connectrpc/connect-query version: 0.5.3
• Frontend framework and version: react@18.2.0
• Node.js version: (for example, 20.6.1)
• Browser and version:
  • Chrome: Version 117.0.5938.149
  • Safari: Version 17.0 (19616.1.27.211.1)
  • Firefox: 118.0.2

Additional context
Should connect be adjusting the user-agent header in the browser? Or is this only supposed to be for node?

We noticed this because safari and ff started getting cors errors after an update

[Timo Stamm]

Hey Greg, the request header was added in v0.13.2.

The rationale was that the header is no longer forbidden (ref), and it seems reasonable to set it for all protocols and clients equally.

We noticed this because safari and ff started getting cors errors after an update

Hm, that was definitely not the intention, apologies. As a quick workaround for anyone running into this problem, this interceptor should remove the header:

createConnectTransport({
  baseUrl: "....",
  interceptors: [
      (next) => (req) => {
        req.header.delete("User-Agent");
        return next(req);
      },
  ],
});

We need to investigate whether we should revert the behavior. If we don't, we need to call out the change in the release notes, and add the header name to cors.ts.

[Greg McKelvey]

apparently firefox and safari have moved forward with allowing the user-agent header to be set, but chrome silently drops the header from fetch requests (bug report, relevant stackoverflow)

With the browser inconsistency, I'm not sure overriding the user-agent is the best approach. It makes it hard predict, but also would cover up what kind of client is sending requests.

I think adding this information as a custom header that be set in an application's cors allow list will both be more predictable and informative.

---

I ended up implementing the above fix on friday to avoid outages, as I've had to do that to get around previous cors errors with connect-protocol-version and x-grpc-web 😆

For those following along, deleting the user-agent header in this way, just removes the connectrpc custom user-agent, and the browser the supplies its proper default.