Loading container data occasionally returns a 401 Unauthorized response.

[fuzzzerd]

Describe the bug

Loading container data occasionally returns a 401 Unauthorized response.

Steps To Reproduce

Load a lot of container data in a short period of time, and observe that some return a 401 Unauthorized

Expected behavior

The binary data to be returned with an HTTP 200 response code (or sometimes a 302 response

fmdata version

v5.0.0

Additional context

Relevant area:

fmdata/src/FMData.Rest/FileMakerRestClient.cs

Lines 1087 to 1100 in ce59967

	protected override async Task<byte[]> GetContainerOnClient(string containerEndPoint)
	{
	// build the request message
	var requestMessage = new HttpRequestMessage(HttpMethod.Get, containerEndPoint);
	// include auth token on the request
	requestMessage.Headers.Authorization = _authHeader;
	// send the request out
	var data = await Client.SendAsync(requestMessage).ConfigureAwait(false);
	// read the bytes as a stream
	var dataBytes = await data.Content.ReadAsByteArrayAsync().ConfigureAwait(false);
	return dataBytes;
	}

Observed as:

IIS Log Snip:

2023-06-07 22:02:39 127.0.0.1 GET /Streaming_SSL/Additional_1/[redacted].png RCType=RCFileProcessor&Redirect&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=[redacted]&SERVER-STATUS=401 443 - 127.0.0.1 FMData.Rest/5.0.0+4cf2ece2fb68fe28090ec45fceeb0d74bf984cb3 - 401 0 0 36

Others on the Claris forms have added [special retry logic for this scenario.](You can get a 401 error if the cookie jar wasn't set up properly; I haven't seen a 400 error in this particular case. I had to put some code into fmPDA to handle the 401 and do a retry to help resolve the issue. It's unfortunately one of the less smooth parts of how the Data API behaves.)

You can get a 401 error if the cookie jar wasn't set up properly; I haven't seen a 400 error in this particular case. I had to put some code into fmPDA to handle the 401 and do a retry to help resolve the issue. It's unfortunately one of the less smooth parts of how the Data API behaves.

[fuzzzerd]

This seems NOT to happen with a simple

var client = new FileMakerRestClient();
var data = await client.SendAsync(...find request)
await client.ProcessContainers(data);

and seems to have something to do with being added to the ASP.NET DI system, possibly due to cookie sharing when, see also: tmenier/Flurl#506, dotnet/runtime#1904

[fuzzzerd]

FileMaker Container data urls are secured by a Cookie, that is set on First access of the URL. We're using managed IHttpClientFactory to generate HttpClients and those share a CookieContainer which is likely getting reset and/or mismatched across outbound requests. Possibly due to the default lifetime of the HttpClientHandler.

As noted above, newing up a client directly and hammering it with repeated requests to load data and then associated container data does NOT produce this error ever.