Is RequestLocalizationMiddleware thread-safe?

[AndreuCodina]

My use case is the next: a RESTful endpoint will be exposed to millions of users. This endpoint will return a string (stored in a resx), but in the language requested by the client with the HTTP header Accept-Language.

For that, I've added the next line of code to Program.cs:

app.UseRequestLocalization();

With this, you add the middleware RequestLocalizationMiddleware. It internally calls the method SetCurrentThreadCulture, and this sets the next properties:

• CultureInfo.CurrentCulture = requestCulture.Culture;
  Description: Gets or sets the CultureInfo object that represents the culture used by the current thread and task-based asynchronous operations.
• CultureInfo.CurrentUICulture = requestCulture.UICulture;
  Description: Gets or sets the CultureInfo object that represents the current user interface culture used by the Resource Manager to look up culture-specific resources at run time.

Given those descriptions and the amount of incoming HTTP requests to the endpoint, I have the next doubts:

1. Can I have collisions, so a user can receive a language requested from another user?
2. If I don't use "async Task" in the endpoint, will I have collisions or any problem?

The documentation doesn't clarify this: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/localization/select-language-culture?view=aspnetcore-8.0

[davidfowl]

Short answer yes, it’s thread safe. If it wasn’t it would be unusable.

Current culture is an async local. It’s a local that implicitly flows throughout async calls (conceptually like a thread local but for async code)