[MRG+1] response_status_message should not fail on non-standard HTTP codes #1857
Conversation
utility is used in retry middleware and it was failing to handle non-standard HTTP codes. Instead of raising exceptions when passing through to_native_str it should return "Unknown status" message.
Current coverage is
|
Quoting RFC 7231, section 6
so I suggest we use reason phrases from their class "x00" status code. |
this utility should actually handle all status codes which are not HTTP standard compliant, so some theoretical status code 391 or 254 or even some status 12900 as well. The way it currently works is that it doesn't check if status is from 4** or 5** range. Are you suggesting we should handle invalid statuses from different classes in different ways? It would add some complexity to handle differences between invalid status codes in 3xx or 4xx or 5xx ranges. Or are you saying that "Unknown Reason" is just better message for all possible invalid HTTP status codes? EDIT: BTW I've chosen "Unknown Status" because it follows Twisted convention http://twistedmatrix.com/trac/browser/tags/releases/twisted-16.0.0/twisted/web/http.py#L1035 |
@pawelmhm , I was suggesting to use 200, 300, 400, 500 reasons for their respective classes and "Unknown Reason" for invalid classes. |
I just realized that the actual reason is not available in the response. |
I liked doctest more because it is useful as documentation, not only as a test. |
This comment has been minimized.
This comment has been minimized.
Just ran into this! |
utility is used in retry middleware and it was failing to handle non-standard HTTP codes. Instead of raising exceptions when passing through
to_native_str
it should return "Unknown status" message.