[patch] fixing (10053, 'Software caused connection abort') error

[eugene@…]

This patch suppresses logging of connection aborts, which are quite normal, especially with prefetching. I got them pretty frequently with Django's runserver. They are mostly harmless but distracting:

Traceback (most recent call last):
  File "C:\Python24\lib\site-packages\django\core\servers\basehttp.py", line 273
, in run
    self.finish_response()
  File "C:\Python24\lib\site-packages\django\core\servers\basehttp.py", line 312
, in finish_response
    self.write(data)
  File "C:\Python24\lib\site-packages\django\core\servers\basehttp.py", line 391
, in write
    self.send_headers()
  File "C:\Python24\lib\site-packages\django\core\servers\basehttp.py", line 443
, in send_headers
    self.send_preamble()
  File "C:\Python24\lib\site-packages\django\core\servers\basehttp.py", line 372
, in send_preamble
    self._write(
  File "C:\Python24\lib\socket.py", line 256, in write
    self.flush()
  File "C:\Python24\lib\socket.py", line 243, in flush
    self._sock.sendall(buffer)
error: (10053, 'Software caused connection abort')

[Adrian Holovaty]

This solution -- isolating that particular exception -- seems a bit hackish and special-casish. Any other way to solve the problem at a different level in the code?

[Adrian Holovaty]

Solution is too hackish, so I'm closing.

[eugene@…]

There is no other solution. And it is all about the special case --- clients can abort web connections at will and it is normal behavior. We see the 10053 "error" on Windows because Python's implementation on Windows propagates it to the code, while Unix implementation eats it up. BTW, it was introduced by a Python update (Python 2.4.2?). Before that it worked identically on both platforms --- that's why we didn't see it before.

I am reopening it "just in case". It's up to you to make a final call. At the end of the day it is harmless.