uvicorn: Stuck with: WARNING: Invalid HTTP request received.
Hi there,
I’m using FastAPI with uvicorn and I’m running into an issue which I’m not sure how to debug/solve. I wasn’t sure where to post this, but since the error message comes from uvicorn I decided to post it here.
There is no issue if I send a single GET request:
DEBUG: ('10.144.0.115', 48348) - Connected
DEBUG: ('10.144.0.115', 48348) - ASGI [48] Started
DEBUG: ('10.144.0.115', 48348) - ASGI [48] Received {'type': 'http.response.start', 'status': 200, 'headers': '<...>'}
INFO: ('10.144.0.115', 48348) - "GET /charts HTTP/1.1" 200
DEBUG: ('10.144.0.115', 48348) - ASGI [48] Received {'type': 'http.response.body', 'body': '<41112 bytes>'}
DEBUG: ('10.144.0.115', 48348) - ASGI [48] Completed
DEBUG: ('10.144.0.115', 48348) - Disconnected
But if I send a second GET request while the connection from the first request is still open I get WARNING: Invalid HTTP request received.. Here is the complete log for the two requests:
DEBUG: ('10.144.0.115', 49422) - Connected
DEBUG: ('10.144.0.115', 49422) - ASGI [51] Started
DEBUG: ('10.144.0.115', 49422) - ASGI [51] Received {'type': 'http.response.start', 'status': 200, 'headers': '<...>'}
INFO: ('10.144.0.115', 49422) - "GET /charts HTTP/1.1" 200
DEBUG: ('10.144.0.115', 49422) - ASGI [51] Received {'type': 'http.response.body', 'body': '<41112 bytes>'}
DEBUG: ('10.144.0.115', 49422) - ASGI [51] Completed
WARNING: Invalid HTTP request received.
DEBUG: ('10.144.0.115', 49422) - Disconnected
DEBUG: ('10.144.0.115', 49430) - Connected
DEBUG: ('10.144.0.115', 49430) - ASGI [52] Started
DEBUG: ('10.144.0.115', 49430) - ASGI [52] Received {'type': 'http.response.start', 'status': 200, 'headers': '<...>'}
INFO: ('10.144.0.115', 49430) - "GET /charts HTTP/1.1" 200
DEBUG: ('10.144.0.115', 49430) - ASGI [52] Received {'type': 'http.response.body', 'body': '<41112 bytes>'}
DEBUG: ('10.144.0.115', 49430) - ASGI [52] Completed
DEBUG: ('10.144.0.115', 49430) - Disconnected
This isn’t too bad, because I still receive the responses for each request, even with the warning.
But if I try to send a POST request from a react-frontend it gets worse. The POST request from the frontend comes with a Preflight OPTIONS request. That means if I hit the send-button in the frontend the browser sends an OPTIONS request immediately followed by a POST request.
The server log looks like this:
DEBUG: ('10.144.0.115', 44982) - Connected
DEBUG: ('10.144.0.115', 44982) - ASGI [14] Started
DEBUG: ('10.144.0.115', 44982) - ASGI [14] Received {'type': 'http.response.start', 'status': 200, 'headers': '<...>'}
INFO: ('10.144.0.115', 44982) - "OPTIONS /colors HTTP/1.1" 200
DEBUG: ('10.144.0.115', 44982) - ASGI [14] Received {'type': 'http.response.body', 'body': '<2 bytes>'}
DEBUG: ('10.144.0.115', 44982) - ASGI [14] Completed
WARNING: Invalid HTTP request received.
DEBUG: ('10.144.0.115', 44982) - Disconnected
The OPTIONS request gets through, but the POST request doesn’t. The payload from the frontend doesn’t reach the backend.
Now the strangest thing: If I hammer the send-button multiple times a second, the POST request will get through eventually.
Does anyone know what’s going on or how this could be solved?
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 18 (6 by maintainers)
Hi there, I do have the same issue but I can’t replicate it locally, I only see it on a deployed kubernetes cluster.
I am using gunicorn and the issue disappear if I switch from uvicorn.workers.UvicornWorker to uvicorn.workers.UvicornH11Worker.
It seems related to #344
@euri10 Just rebuilt our image using latest base image. Uvicorn is 0.11.3 and gunicorn is 20.0.4.
The issue persists when we turn on CORS and Azure inserts its middleware to handle CORS.
Update: @euri10 Adding the following environment variable is a work-around for this issue:
GUNICORN_CMD_ARGS="--keep-alive 0"@MrMathias
We are having the exact issue you are.
I was able to get the logs for my app. Looks like when you turn on CORS Azure App Service adds an ASP.NET middleware container, that isn’t there when no hosts are added in Azure portal. Once you add a host (even ‘*’), this container show up.
Maybe the issue lies in how the ASP.NET container is forwarding requests? If that is indeed what it’s doing.
Thanks for your reply!
I already tried this, without luck:
Another thing I noticed:
POSTrequest send viaIsomnia(Rest API client) gets through without errors:200 Ok.POSTrequest send viaInsomia1 second after the first one won’t get through:502 Bad Gateway.POSTrequest send viaInsomia5 seconds after the first request will get through:200 Ok.To break the whole thing down a bit:
The server can handle ONE request just fine, but it fails in different ways, as soon as a SECOND request is send from the same user while the connection is still open.
Update
I found out that the issue doesn’t exist if I start
uvicornwithtimeout_keep_alive=0.