Request Timeouts dynamically calculated

[bradlis7]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I am trying to set the timeout of my request dynamically, but it seems it must be a constant value.

Describe the solution you'd like

I would suggest that UseRequestTimeouts have a callback option with the request context to be evaluated and set the timeout value inside of this callback.

Additional context

I am using .net in Lambda, and I could use ILambdaContext.RemainingTime - buffer to determine when the timeout should happen, but I don't see how to do so with the current implementation.

[martincostello]

Taking a quick look at the code, it doesn't look like it's possible to dynamically determine the timeout.

Maybe you could manually do something like the internals do by manually implementing and setting a IHttpRequestTimeoutFeature in a middleware like how the timeout middleware does itself?

aspnetcore/src/Http/Http/src/Timeouts/RequestTimeoutsMiddleware.cs

Lines 96 to 108 in 207bc7d

	async Task SetTimeoutAsync()
	{
	var originalToken = context.RequestAborted;
	var (linkedCts, timeoutCts) = _cancellationTokenProvider.GetLinkedCancellationTokenSource(context, originalToken, timeSpan.Value);
	try
	{
	var feature = new HttpRequestTimeoutFeature(timeoutCts);
	context.Features.Set<IHttpRequestTimeoutFeature>(feature);
	context.RequestAborted = linkedCts.Token;
	await _next(context);
	}

[bradlis7]

Maybe you could manually do something like the internals do by manually implementing and setting a IHttpRequestTimeoutFeature in a middleware like how the timeout middleware does itself?

That's a good workaround, I'll do that for now.

[bradlis7]

So many internal classes... in order to create a workaround, I have to copy a bunch of classes in. I guess I'll just use static timeouts for now.