Сомнительное решение для ошибки сломанной трубы в Django

Question

В моем приложении django я вызываю location.reload(); в рутине Ajax в некоторых редких случаях. Это хорошо работает с Chrome, но с Firefox4 я получаю error: [Errno 32] Broken pipe дважды на моем сервере разработки (Django 1.2.5, Python 2.7), что занимает около 10 секунд.
И ошибка, кажется, съедает сообщение, которое я пытаюсь отобразить с помощью структуры сообщений django.

Нет, я заменил эту строку на

var uri = location.href;
location.href = uri;

Теперь перезагрузка все еще занимает около 10 секунд, но Firefox отображает сообщение.

Пока это работает. Но для меня это выглядит как грязный хак. Итак, мои вопросы:

1. Кто-нибудь может объяснить (или угадать), в чем вообще ошибка?
2. Видите ли вы какие-либо проблемы, когда это «решение» может укусить меня в будущем?

(Примечание: я не первый до опыт , что проблема ).

Answer 1

Прежде всего, это проблема с некоторыми конкретными браузерами (и, вероятно, длительная обработка на стороне сервера), не проблема в django.

Из сообщения об ошибке в django:

Это распространенная ошибка, которая возникает, когда ваш браузер закрывает соединение, пока сервер разработки все еще занят отправкой данных. Лучшее, что мы могли бы сделать, это иметь более явное сообщение об ошибке.

На самом деле это может происходить в других системах, например, из cherrypy

Не о чем беспокоиться, так как это означает, что клиент закрыл соединение до сервера. После этой трассировки ваш сервер CherryPy будет продолжать работать в обычном режиме.

Итак, это введение в ваш первый вопрос:

1. Кто-нибудь может объяснить (или угадать), в чем вообще ошибка?

Ну, это просто браузер, закрывающий соединение - своего рода тайм-аут на стороне клиента. Этот Django + WebKit = Сломанный канал ответ действительно отвечает на этот вопрос.

Почему это работает, изменив location.href и не используя location.reload()? Ну, я бы догадался, но это ТОЛЬКО предположение, что Firefox ведет себя немного по-другому, а перезагрузка будет по-разному.

Я думаю, что сообщение используется, потому что запрос уже отправляется, когда браузер нажимает на триггер и закрывает соединение.

Сервер dev является однопоточным, что также может быть причиной проблемы.

Обычно я делаю свою разработку на реальном (локальном) сервере (nginx + apache + mod_wsgi, ничего особенного), чтобы избежать глупых проблем, которые никогда не возникнут на производстве.

2. Видите ли вы какие-либо проблемы, когда это «решение» может укусить меня в будущем?

Ну, это может не работать в браузере, который проверяет, изменился ли href перед перезагрузкой. Или он может попасть в кеш вместо выполнения реального запроса (вы можете принудительно избежать кеша с помощью reload ()). И поведение может быть не согласованным во всех браузерах. Но, опять же, вы уже столкнулись с особенностями браузера, так что я бы не стал особо волноваться об этом.

Кстати, вы могли бы просто сделать:

location.href = location.href

Я бы предпочел беспокоиться, что обработка займет 10 секунд! Это действительно не должно случиться. edit Похоже, что сам браузер провоцирует длительное время обработки И ошибку сломанного канала. звучит как (плохие) параллельные запросы на однопоточном сервере django для меня. EndEdit

Тестируйте на реальном веб-сервере, оптимизируйте свой код; если этого недостаточно, запустите длинные задачи в фоновом режиме с помощью celery + rabbitmq; ни в коем случае не теряйте времени на проблему, которая на самом деле не является проблемой!

Вы, вероятно, сможете жить с location.reload() и немного подправить ИЛИ, может быть, просто настоящую тестовую среду!

Answer 2

Ошибка прерванного канала также может быть связана с отсутствием поддержки определенных функций на сервере отладки Django - одной заметной проблемой является отсутствие поддержки Django для Range HTTP-запросов (подробности см. Здесь: Байт в Django ), которые обычно используются при доставке [потокового] ​​мультимедийного содержимого.

Вероятно, стоит изучить фактический HTTP-обмен с помощью программы захвата пакетов, такой как Wireshark, чтобы вы могли увидеть, гдеи когда проблема возникает.