[заявление об отказе: это объяснение «почему это нелегко сделать», а не решение]
Как заметил @Slott, это определенно технически правильное поведение, когда stream.close или stream.write вызывается в закрытом сокете. Однако я понимаю мотивацию вопроса ... в контексте приложения wsgi клиенты, разрывающие соединение после полного или частичного чтения, не являются «исключительным» поведением, это происходит постоянно. Для того, чтобы его оставить необработанным, создается впечатление, что оно было неожиданным / код не был подготовлен для этого, хотя на самом деле это ожидаемо и не должно быть достойным внимания. Так что было бы неплохо исправить.
Сложность в том, что вам нужно найти способ различать дела ...
Ситуации, такие как "клиент прочитал 'Статус: 304', а затем закрыл соединение" или "клиент прочитал все байты, а затем закрыл соединение, даже если он запросил соединение, должно быть повторно использовано", это ситуации, где это будет целесообразно не выдавать никаких журналов, кроме вызова log.debug().
Но такие ситуации, как «клиент прекратил чтение в середине файла, потому что соединение оборвалось, когда у маршрутизатора ISP произошел удар», достойны регистрации ошибки. Что-то не удалось успешно завершить, и любое состояние транзакции, созданное вашим серверным приложением, следует откатить. В этом случае IOError распространяется вверх - это правильно.
Такие ошибки можно заставить замолчать только в том случае, если в каждом месте, где они могут возникнуть, код будет изменен для различения этих двух случаев. До этого авторы wsgi, по-видимому, ошибались из-за осторожности. Так что я не знаю, как быстро это исправить.
(Кроме того, я должен отметить, что это не специфично для django, я использую paste + pylons и происходит то же самое)