You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Target groups with Lambda targets don't have health checks turned on by default. If you turn on health checks for an ASP.Net Core app using the ApplicationLoadBalancerFunction.FunctionHandlerAsync handler, health checks will fail and the Lambda will emit exception stack traces.
The Lambda request payload for health checks is documented here as looking like:
The properties after Scheme probably fail too, but this is the first to fail.
Solution:
Given that ASP.Net Core appears to treat these properties as non-null, we should probably populate them unconditionally. Any value will be better than no value. Any thoughts about how you'd best like to approach this? I'd be happy to submit a PR fixing it with unit test coverage.
The text was updated successfully, but these errors were encountered:
That is an interesting one. I'm afraid to just default the value to https in case there is a situation that is not correct. I wonder if we should look to see if the user-agent starts with "ELB-HealthChecker" and if so default schema to https.
Hi,
Background:
Target groups with Lambda targets don't have health checks turned on by default. If you turn on health checks for an ASP.Net Core app using the
ApplicationLoadBalancerFunction.FunctionHandlerAsync
handler, health checks will fail and the Lambda will emit exception stack traces.The Lambda request payload for health checks is documented here as looking like:
Problem:
This line of code is what parses the scheme:
aws-lambda-dotnet/Libraries/src/Amazon.Lambda.AspNetCoreServer/ApplicationLoadBalancerFunction.cs
Line 63 in 6414d0b
After this line runs for the above request payload,
requestFeatures.Scheme
is stillnull
. This causes a null reference exception here:https://github.com/aspnet/Hosting/blob/1da228d28fdfcfb2d77241c4e0413efec1beeafd/src/Microsoft.AspNetCore.Hosting/Internal/HostingRequestStartingLog.cs#L37
The properties after
Scheme
probably fail too, but this is the first to fail.Solution:
Given that ASP.Net Core appears to treat these properties as non-null, we should probably populate them unconditionally. Any value will be better than no value. Any thoughts about how you'd best like to approach this? I'd be happy to submit a PR fixing it with unit test coverage.
The text was updated successfully, but these errors were encountered: