XMLHttpRequest не завершается при запросе на удаление через прокси-сервер в IE11

#angular #typescript #internet-explorer-11 #http-proxy

#angular #машинопись #internet-explorer-11 #http-прокси

Вопрос:

У меня есть приложение Angular2 (2.0.1), которое вызывает ReST API в серверном приложении Джерси. В Internet Explorer 11 проблема заключается в том, что запросы на УДАЛЕНИЕ выполняются правильно, но обратный вызов выполняется не сразу. Только через 120 секунд (я думаю, некоторое время ожидания) вызывается обратный вызов. На сетевом уровне я вижу немедленный ответ, поэтому я предполагаю, что проблема либо в IE, либо в http-библиотеке Angular2, вероятно, только в случае ответа «204 Нет содержимого».

[Редактировать]: Также запросы GET ведут себя таким образом в случае пустого ответа со статусом 204.

Как вы можете видеть в инструментах разработчика, запрос находится на рассмотрении в течение некоторого времени: Состояние ожидания

Через 120 секунд запрос завершен. В это время вызывается функция обратного вызова: Завершено через 120 секунд

Обратите внимание, что это происходит только в том случае, если доступ к внутреннему API осуществляется через наш корпоративный прокси-сервер, и только в IE 11.

Вызов запускается следующим образом:

 doDelete(id: string) {
    this.http.delete(this.deleteUrl   id)
        .subscribe(
            data => { this.ngOnInit(); },
            error => { window.alert(error) });
}
  

Здесь трассировка сети:

 DELETE http://yyy.yyy.at/types/76856ad1-342c-41d0-a627-71cd02d586a8 HTTP/1.1
Accept: */*
authorization: Bearer b50cd05c-0314-4557-aa66-cf9c9f356e31
Referer: http://yyy.yyy.at/types
Accept-Language: de-AT
Origin: http://yyy.yyy.at
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Content-Length: 0
Host: yyy.yyy.at
Proxy-Connection: Keep-Alive
Pragma: no-cache

HTTP/1.0 204 No Content
Date: Fri, 07 Oct 2016 06:54:45 GMT
Server: Apache-Coyote/1.1
Cache-Control: no-cache
Access-Control-Allow-Origin: http://yyy.yyy.at
Access-Control-Allow-Credentials: true
Set-Cookie: 9047e7349d0e3de4224ae4053da5d560=b44c49344740b5a0b58b8fdd51b15bdc; path=/; HttpOnly
X-Cache: MISS from xxx.xxx.net
X-Cache-Lookup: MISS from xxx.xxx.net:8080
X-Cache: MISS from xxx.xxx.at
X-Cache-Lookup: MISS from xxx.xxx.at:8080
Via: 1.1 PSxxx, 1.1 xxx.xxx.net:8080 (squid/2.7.STABLE9), 1.0 xxx.xxx.at:8080 (squid/2.7.STABLE9)
Connection: keep-alive
Proxy-Connection: keep-alive
  

Комментарии:

1. Я нашел обходной путь, чтобы ответить кодом 200 вместо 204 и установить «Content-Length: 0».

Ответ №1:

Internet Explorer 11 тоже сделал это для меня, но старательно убедившись, что значение Content-Length установлено в 0, исправил это для меня, даже с HTTP 204 в качестве кода ответа.

Если у кого-то еще возникает эта проблема, самый простой способ узнать, является ли это проблемой тайм-аута в Internet Explorer, — это прервать / перезапустить ваш сервер API, пока IE (неправильно) ожидает данных. Поскольку прерывание приведет к прерыванию TCP-соединения, IE проверит, какие данные у него есть, и попытается выполнить — в конце концов, код состояния говорит, что произошел успех, и поскольку на самом деле не должно быть никакого содержимого, ваш код, скорее всего, будет работать в любом случае.

В моем случае тайм-аут наступил примерно через 60 секунд, но это, вероятно, связано с тем, что моя конфигурация AWS Elastic LoadBalancer поддерживает незанятые соединения открытыми так долго.