Как долго браузер будет ждать после запроса ajax?

Как долго браузер может ждать, прежде чем появится ошибка, прежде чем сервер ответит на запрос? Может ли это время быть неограниченным?

58
ajax connection-timeout request

4 ответов

Если вы используете jQuery с $.вызов ajax можно задать свойство timeout для управления временем до возвращения запроса со статусом timeout. Тайм-аут устанавливается в миллисекундах, поэтому просто установите его на очень высокое значение. Вы также можете установить его в 0 для "безлимитный", но на мой взгляд, вы должны просто установить высокое значение.

Примечание: неограниченное составляет на самом деле по умолчанию но большинство браузеров имеют таймауты по умолчанию, будет нажмите.

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

поэтому, если вы хотите установить тайм-аут в 3 секунды и обработать тайм-аут, вот пример:

$.ajax({
    url: "/your_ajax_method/",
    type: "GET",
    dataType: "json",
    timeout: 3000, //Set your timeout value in milliseconds or 0 for unlimited
    success: function(response) { alert(response); },
    error: function(jqXHR, textStatus, errorThrown) {
        if(textStatus==="timeout") {  
            alert("Call has timed out"); //Handle the timeout
        } else {
            alert("Another error was returned"); //Handle other error type
        }
    }
});​
67

да и нет. Да, сервер может это сделать или быть настроен для этого, никакие браузеры (я не знаю о специфике версии/распространителя) не могут иметь тайм-аутов.

есть 2 решения, хотя для достижения / эмуляции этого по HTTP:

  • если это простой длительный сценарий, и вы ждете результатов, это не путь, вы должны вместо этого сделать, как предыдущий плакат, упомянутый и использовать асинхронную обработку с опросом сервера для результатов, это будет будьте гораздо более уверенным решением огня. Например: сценарий эскиза со стороны сервера обработчика изображений: пользователь загружает изображение сервер imidiatly возвращает 200 и "идентификатор задания". Затем клиент (javascript^^) может использовать JobID для запроса состояния/результата задания.
  • если ваша цель состоит в том, чтобы иметь что-то вроде подключения в реальном времени между браузером и сервером (1 способ подключения, как только запрос сделан браузером, никакая дополнительная информация не может быть отправлена без использования новых запросов (ajax^^)), это называется long polling / reverse ajax и может использоваться для связи в реальном времени по http. Существует несколько методов, использующих 2 длинных опрошенных запроса параллельно, так что как только один из них тайм-аут, второй становится активным, а первый пытается снова подключиться.
14

можете ли вы объяснить немного больше о том, что вы пытаетесь достичь - у вас давно запущенный процесс на сервере, вы хотите изменить настройки на локальном компьютере или вы после образом управлять им для большого количества пользователей?

Как долго браузер будет ждать, зависит от ряда факторов, например, где происходит тайм-аут - на уровне TCP, сервера или локального браузера?

Если у вас давно запущенный процесс на сервере и вы хотите обновление веб-страницы после этого типичный способ обработки-запустить длительный процесс асинхронно и уведомить клиента, когда он будет завершен, например, иметь вызов ajax, который опрашивает сервер, или использовать HTTP 1.1 и обслуживать поток уведомлений клиенту.

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

3

Я обнаружил, что в случае обычного (HTML-страницы) запроса браузеры запускаются до таймаута после cca. 30 сек. Это важно, потому что другие участники, вероятно, следуют за ним: прокси ,маршрутизаторы (маршрутизаторы играют в эту игру? Я не уверен). Я использую 4 сек длительная задержка на стороне сервера (если клиенту нечего отправлять), и мой клиент AJAX выполняет другой HTTP-запрос немедленно (я нахожусь в локальной сети, нет задержки в интернете). 4 сек достаточно долго, чтобы не перегружать сервер и сеть с часто посещаемыми опросами, и достаточно коротки для случая, когда каким-то образом один опрос выпадает из строки, которую клиент не может обнаружить и обработать.

кроме того, есть и другие проблемы с comet (long HTTP request): ограничение браузера на количество одновременных HTTP-запросов, обработка событий на стороне клиента (необходимо отправить на сервер немедленно), обнаружение и восстановление сервера/сети, многопользовательская обработка и т. д.

2