-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
error_status_hint = 400 even when we are the client #41
Comments
Breaking changes are possible -- see #17. (It sounds like you might want to subscribe to #17 in any case.) I'm a little unclear on how you're imagining this being used; can you elaborate? I guess the way I was conceptualizing it was, we give as precise a code as we can to describe what the error was, and then it's up to you what to do with this information. (If you're a client, probably not much.) LocalProtocolErrors also have the hint, which is even more useless. I guess it means something like "if I had allowed you to send this (and that actually were possible), and the peer was a server at a point in the state machine where they send back an error status, then this is the one they would send"? Which reminds me that there's also the case where we are in server mode, and get a nice We can't really change how LocalProtocolErrors work because at the point where they're generated we don't necessarily have access to connection state information (e.g. they can be raised by event object constructors). For RemoteProtocolErrors there is a single point where they're constructed and it does have access to connection state information. But I don't have a clear concept of what the goal would be? |
In the (toy) app that I’m building with h11, I have a catch-all error handler modeled after your Curio example. And then inside the actual request handler I sometimes operate a gateway: I open a socket to an upstream server and forward the request to it using h11. Now, if the upstream server misbehaves, I get a Of course, I can easily catch |
This prints:
The
error_status_hint
might make sense whenour_role=h11.CLIENT
insofar as a server may be acting as a gateway. In that case, it may be more useful to have this hint set to 502 (Bad Gateway). Or perhaps removed altogether, so that (presumably) the server’s default 5xx kicks in — but this would be a breaking API change.The text was updated successfully, but these errors were encountered: