Clarifying HTTP exception behavior wrt. 500 responses. about asgiref HOT 8 OPEN

OK - I won't be able to get to either in the short term, but will leave this open to track the work.

from asgiref.

Behavior now changed in uvicorn 0.3.5.

from asgiref.

So what needs doing here - clarification in the spec and also a fix to WsgiToAsgi?

from asgiref.

Not some much a clarification in the spec (since it doesn't yet discuss exceptions from the ASGI callable, aside from send/receive exceptions), as an addition.

I suppose at some point the HTTP section ought to have an Exceptions section, which details the differences between WSGI's exc_info, and ASGI's "send the response, then raise the exception".

The main overview currently has an "exceptions" section which could note that "exceptions raised by the ASGI application should close the connection, and may also return an appropriate error message, such as an HTTP 500 response (then link to HTTP spec for fuller details)."

And yes, also a fix to the middleware.

I'll start by considering the docs change as being on my backlog, but equally happy if you or anyone else is able to get there first.

from asgiref.

Related to this may be some tightening up on specification around how exceptions within send/receive should be treated be applications (i.e. they must be treated as opaque) and making explicit that "send"ing to disconnected connection shouldn't result in an exception, but should be silently allowed. (eg. see discussions about websocket handling in encode/starlette#58 (comment) and encode/starlette#56 which are discussions that arise out of both spec and implementation being a bit wooly there at the moment.)

from asgiref.

Hmm, is there a reason to not raise a known error if you send down a disconnected connection? I know we could just as easily make it vanish into the void, but that seems harder to debug in the edge case.

from asgiref.

Okay, I'm going to open a seperate ticket to discuss this (#66) since I think it's a bit of a thorny question, and really it's seperate to this ticket which is "how should applications handle exception, particularly wrt. issuing technical 500 responses", and which I think is basically resolved.

from asgiref.

@tomchristie Do you think there's more work we need to do here?

from asgiref.