Open gaborbernat opened 1 month ago
This is confirmed, and it happens on ASGI pathsend
responses and RSGI response_file
responses.
The issues is caused by the fact Granian won't block the Python application for file opening and reading; and just making the app waiting for that looks very sub-optimal to me.
Will think about a solution for this in the following days.
Are you going to EuroPython by any chance? :D
Are you going to EuroPython by any chance? :D
Nope, unfortunately this year I won't be able to attend :(
This is confirmed, and it happens on ASGI
pathsend
responses and RSGIresponse_file
responses. The issues is caused by the fact Granian won't block the Python application for file opening and reading; and just making the app waiting for that looks very sub-optimal to me. Will think about a solution for this in the following days.
Hardcode response to 200 if the file exists? 😆 Though would not handle not changed responses...
So, I pushed 72a9a21 that won't fix the actual issue, but at least prevents fake 500 status codes in access logs. This means next revision will report 200 even if Granian is not able to open the file (and thus the real response code will be 404).
I'll keep this opened until I find a proper fix.
I noticed that 200s are logged as 500. Modified https://github.com/emmett-framework/granian/blob/master/granian/asgi.py#L109 with:
Output:
As you can see, the access log is logged before the response is sent, and I assume 500 is the default value.
The response type in question is a
FileResponse
fromstarlette
. When I remove my for loop, the status code logged is always 500.