HTTP status code selection does not allow 0
julianbraasch opened this issue · comments
📑 I have found these related issues/pull requests
None
🛡️ Security Policy
- I agree to have read this project Security Policy
Description
I'm using the gRPC keyword monitor type which I would like to connect to a ChirpStack instance.
I did confirm that my proto file and method are correct by using Postman for the same request. I noticed that Postman lists "0 OK" as the status code of the response. However, I am unable to add 0 as my desired status code in Uptime Kuma. I am not sure if this is actually the reason why this monitor fails.
👟 Reproduction steps
Add new gRPC monitor
👀 Expected behavior
The monitor returns the response of my proto service
😓 Actual Behavior
The monitor reports a failed connection. Ping statistics are available through. No entries in the event list of the monitor itself.
🐻 Uptime-Kuma Version
1.23.15
💻 Operating System and Arch
macOS 15.1
🌐 Browser
Google Chrome 130.0.6723.119
🖥️ Deployment Environment
- Runtime: Docker 4.35.1
- Database: Docker volume
- Filesystem used to store the database on: APFS on a SSD
- number of monitors: 1
📝 Relevant log output
[MONITOR] WARN: Monitor #1 'ChirpStack': Failing: Error in send gRPC 8 Received message larger than max (1752460652 vs 4194304) | Interval: 20 seconds | Type: grpc-keyword | Down Count: 0 | Resend Interval: 0
Received message larger than max
What is the message that the grpc endpoint is responding with?
The result JSON contains a single entry called jwt which contains a JSON Web Token, which admittedly can be quite long
If the message is referring to bits, that would be 219 MB.
If it's bytes that would be 1.7GB
Having a limit against such requests is reasonable.
In postman what is the size of the message in MB?
I concur with enforcing request limits, but I can assure you they are orders of magnitude lower. The response in Postman was just 250 bytes long.
{
"jwt": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdWQiOiJjaGlycHN0YWNrIiwiZXhwIjoxNzMyMDk3MDc3LCJpc3MiOiJjaGlycHN0YWNrIiwic3ViIjoiMDUyNDRmMTItNmRhZi00ZTFmLTgzMTUtYzY2NzgzYTBhYjU2IiwidHlwIjoidXNlciJ9.ZnWatLRzzb3EMo5VVEes-3wzhD3ePJpqt02zqyGnmSs"
}Interesting.
So not really exceeding the limit...