Martin Panter added the comment: I believe the BadStatusLine can still happen, depending on the circumstances. When I get a chance I will see if I can make a demonstration. In the meantime these comments from my persistent connection handler <https://github.com/vadmium/python-iview/blob/587a198/iview/utils.py#L169> might be useful:
# If the server closed the connection, # by calling close() or shutdown(SHUT_WR), # before receiving a short request (<= 1 MB), # the "http.client" module raises a BadStatusLine exception. # # To produce EPIPE: # 1. server: close() or shutdown(SHUT_RDWR) # 2. client: send(large request >> 1 MB) # # ENOTCONN probably not possible with current Python, # but could be generated on Linux by: # 1. server: close() or shutdown(SHUT_RDWR) # 2. client: send(finite data) # 3. client: shutdown() # ENOTCONN not covered by ConnectionError even in Python 3.3. # # To produce ECONNRESET: # 1. client: send(finite data) # 2. server: close() without reading all data # 3. client: send() I think these behaviours were from experimenting on Linux with Python 3 sockets, and reading the man pages. I think there should be a new documented exception, a subclass of BadStatusLine for backwards compatibility. Then user code could catch the new exception, and true bad status lines that do not conform to the specification or whatever won’t be caught. I agree that the library shouldn’t be doing any special retrying of its own, but should make it easy for the caller to do so. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue3566> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
