Healthchecks for destinations running on HTTP1.1 and HTTP/2
See original GitHub issueI use the YARP as gRPC balancer based on of course on HTTP/2. My destinations gRPC server are not using TLS as all of them is internal. So that’s why I have the following settings in YARP config
"HttpRequest": {
"Version": "2",
"VersionPolicy": "RequestVersionExact"
},
But an endpoints for healthchecks are done as REST API with HTTP1.1 (on dotnet 5.0). So that’s why I’m getting the The HTTP/2 server sent invalid data on the connection. HTTP/2 error code ‘PROTOCOL_ERROR’ (0x1)
Can I somehow workaround it on the YARP side? Thanks
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (5 by maintainers)
Top Results From Across the Web
Destination health checks
In the end, the policy marks each destination as healthy or unhealthy based on the HTTP response code (2xx is considered healthy) and...
Read more >Load Balancing | Health Checks | HTTP
HTTP. You can proactively check the health of your backend servers and remove them from the load balancer rotation until they're up and...
Read more >Health checks for your target groups - Elastic Load Balancing
Your Application Load Balancer periodically sends requests to its registered targets to test their status. These tests are called health checks.
Read more >K3224: HTTP health checks may fail even though the node ...
TopicHTTP or HTTPS health monitor requests may fail even though the server appears to respond, as expected, to browser requests.
Read more >Deploying in AWS - healthchecks
The destination for health checks on the targets. If the protocol version is HTTP/1.1 or HTTP/2, specify a valid URI (/ *path* ?...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
There’s a doc update proposed here: https://github.com/microsoft/reverse-proxy/issues/1153#issuecomment-880137670
That’s considered unhealthy by both active and passive checks. If a passive check were the first to notice then the first few responses would still get 503s before it was pulled out of rotation. If you don’t have any healthy destinations left then subsequent requests will also get 503s.