У меня есть веб-приложение AngularJS, которое обращается к концу сервера .NET WebAPI. Аутентификация осуществляется через библиотеку AngularJS-OAuth2. У меня есть приложение и WebAPI, размещенные в локальном хосте под двумя разными номерами портов. Я также включил пакет Microsoft.Owin.Cors на сервере, чтобы обрабатывать междоменные запросы.Почему данные ответа POST не получены в Internet Explorer?
В Chrome запросы GET и POST возвращают данные в интерфейс. Проверяя трафик через Fiddler, я мог видеть, что отправляются две запросы/ответы (предполетные/OPTIONS + актуальные), а также соответствующие заголовки CORS (включая заголовки источника и Access-Control- *) как в запросах, так и в ответах. Все, как ожидалось.
Однако в Internet Explorer мои запросы GET возвращают данные через службу $ http, но POST этого не делает. Я мог проверить, нет ли предпродажных запросов или заголовков CORS (я думаю, что IE рассматривает разные порты как одно и то же происхождение). При проверке запроса/ответа POST в IE через Fiddler я мог наблюдать, что он возвращает статус HTTP 200, но состояние Aborted (с установленным флагом X-ABORTED-WHEN: SendingResponse). Я также мог бы проверить ответ JSON с верными данными.
Я также попытался установить высокий тайм-аут безрезультатно. Вызов $ HTTP выглядит следующим образом:
return $http.post(apiUrl + "/search", service.getParameters(), { timeout: 600000 })
.success(function (data) {...
Скрипач показывает что-то подобное для запроса IE POST:
также (только) в IE, непреднамеренное обновление страницы также запускается с тот же самый щелчок кнопки, что и эта операция POST.
Почему Internet Explorer отменяет только запросы POST, когда правильные данные также возвращаются клиенту, и когда у Chrome нет каких-либо проблем?
Дополнительная информация
Запрос:
POST https://localhost:44321/api//search HTTP/1.1
Content-Type: application/json;charset=utf-8
Accept: application/json, text/plain, */*
Authorization: Bearer <token>
Referer: https://localhost:44322/search
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: localhost:44321
Content-Length: 202
DNT: 1
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: .ASPXANONYMOUS=<cookie>
réponse:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/10.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: <file>
X-Powered-By: ASP.NET
Date: Wed, 10 Feb 2016 13:43:45 GMT
Content-Length: 2284
Скрипач сессии свойства:
SESSION STATE: Aborted.
Request Entity Size: 202 bytes.
Response Entity Size: 2284 bytes.
== FLAGS ==================
BitFlags: [IsHTTPS, ClientPipeReused, ServerPipeReused] 0x19
X-ABORTED-WHEN: SendingResponse
X-CLIENTIP: 127.0.0.1
X-CLIENTPORT: 41889
X-EGRESSPORT: 41890
X-HOSTIP: ::1
X-PROCESSINFO: avp:3584
X-RESPONSEBODYTRANSFERLENGTH: 2,284
X-SERVERSOCKET: REUSE ServerPipe#168
== TIMING INFO ============
ClientConnected: 19:13:42.408
ClientBeginRequest: 19:13:42.444
GotRequestHeaders: 19:13:42.444
ClientDoneRequest: 19:13:42.772
Determine Gateway: 0ms
DNS Lookup: 0ms
TCP/IP Connect: 0ms
HTTPS Handshake: 0ms
ServerConnected: 19:13:42.413
FiddlerBeginRequest: 19:13:42.772
ServerGotRequest: 19:13:42.772
ServerBeginResponse: 19:13:45.360
GotResponseHeaders: 19:13:45.360
ServerDoneResponse: 19:13:45.360
ClientBeginResponse: 19:13:45.360
ClientDoneResponse: 19:13:45.360
Overall Elapsed: 0:00:02.915
The response was buffered before delivery to the client.
== WININET CACHE INFO ============
This URL is not present in the WinINET cache. [Code: 2]
* Note: Data above shows WinINET's current cache state, not the state at the time of the request.
* Note: Data above shows WinINET's Medium Integrity (non-Protected Mode) cache only.
Кажется, это не проблема. Я не проверял его полностью, но я изменил настройки конфиденциальности IE до наименьшего возможного значения в отношении файлов cookie, как это было предложено одним из ответов. – Tru
Это похоже на обновление страницы изгоев, которое происходит сразу после запроса XHR, который полностью отменяет запрос. – Tru
Сомнительный. Вы пишете «Я думаю, что IE обрабатывает разные порты как одно и то же происхождение», а с другой стороны, вы пишете, он отправляет запрос предварительной проверки OPTIONS, который он будет делать только в ситуации CORS. Однако, возможно, вы также должны добавить код вашего обработчика кликов или что-то другое, вызывающее вызов AJAX. –