Requests sent with RestServerConnector break Query API due to Accept-Language header

Migration
1

During the migration to the latest version of A12, I found out that sending any Query RPC operation using
ConnectorLocator.getInstance().getServerConnector().fetchData(...)
results in some “Unable to construct query for unsupported locale” error.

After digging a bit into this problem, I found out that just in this specific case the “Accept-Language” header is not set anywhere to the selected locale, and the browser takes over the value and (depending on the setting) can add things like “pl,en_US;q=0.9,en;q=0.8,it;q=0.7”.

For now, I am stuck doing something like this:

const localizeRequest = (request: RestRequestPayload, locale: Locale): RestRequestPayload => {
    const requestWithLocalizedHeaders: typeof request = {
        ...request,
        customHeaders: [...(request.customHeaders ?? []), ["Accept-Language", locale.language]]
    };

    return requestWithLocalizedHeaders;
};

const serverConnector = ConnectorLocator.getInstance().getServerConnector() as RestServerConnector;
const localizedRequest = localizeRequest(JsonRpc2Request.build(requests), locale);
const response = await serverConnector.fetchData(localizedRequest);
2

Hi @m.stepniewski,

this is a known change with 2025.06. It is unfortunately not documented explicitly right now, but the following note will be added soon:

The Accept-Language header has to be set to a valid A12 locale, e.g. using the locale of the current A12 user, because it is checked if the provided locale is present as a locale in the queried document model (DM). If the language is not present, the query will fail with an error. Currently, this check is performed case-insensitively, meaning that en and EN are treated the same. However, with a locale in upper case no results are found for a query on localized fields.

The Server Connector has never set the Accept-Language as a default header since it doesn’t know the user’s current locale. It worked before simply because DS didn’t validate this header.

Manually setting the header to your app’s current locale before every request (like you’re doing) is the correct approach. Just make sure the locale matches one from your Document Model.

One more heads-up: The Server Connector currently treats customHeaders as a complete set of headers and will ignore the default headers (Accept and Content-Type). So you might also have to set those default headers for now. This behavior will be improved with A12-17710, but since it is a breaking change, it will come next June at the earliest.

Sorry this detail wasn’t clearer upfront! We’ll be updating the documentation soon to make this more visible. Please let me know if you have any other questions.

Best,
Denise