Пожалуйста, смотрите в конце, так как я постоянно обновляю последние данные исследования. В настоящее время мне нужна помощь с журналом WireShark на стороне сервера.Проблема с поддержкой SSL? (было: веб-страница зависает, только очистка кеша браузера)
Я испытываю странные проблемы с веб-приложением ASP.NET MVC. Немногие пользователи получают форму тайм-аутов и зависаний, так что после нажатия на кнопку она просто длится вечно и не переходит на следующую страницу. Странно, что это устраняется путем очистки кеша браузера. Я не понимаю, как эти две вещи могут быть связаны. Кроме того, пользователь сообщил, что это происходит в FireFox 3+, но не происходит в FireFox 1.5 и 2.0. Я и многие пользователи не могут воспроизвести это, на IE, любой FireFox и Linux/Windows.
Как и почему кеш браузера может повлиять на обработку формы POST?
ОК Я проверил пользователей и FireBug. Я вижу запрос POST, и он терпит неудачу после длительного таймаута. Сервер не получает запрос - по крайней мере, не OnBeforeExecuting базового контроллера, где я выполняю протоколирование, ни в файлах журнала IIS. Ответ пуст. Кроме того, как только запрос занял много времени, но, наконец, выполнен - и на сервере я вижу, что для выполнения требуется очень мало времени.
Насколько я вижу, это происходит в запросах AJAX, выполненных с помощью плагина jQuery Form. Я попытался установить кеш: false в параметрах, без успеха.
На самом деле, я пробовал без AJAX, простой submit - то же самое. Я также вижу, что плагин jQuery формы вызывает $ .ajax() и возвращает. Я вижу, что он инициирует запрос POST. Но я не вижу этот запрос на сервере в журналах IIS, пока, иногда, через минуту - и иногда он прерывается в панели FireBug .Net.
Забавная вещь, это то, что очистка кеша/куки-файлов FireFox/форма & после данных помогает - для одной попытки следующий пост также зависает.
Кроме того, запросы отправляют информацию о выбранных компонентах в виде идентификаторов GUID. Когда компоненты не выбраны, он работает нормально. Компоненты на самом деле скрыты флажками, проверенными JavaScript (не во время отправки, раньше). Это «выбранный» параметр в данных POST. Похоже, что когда нет выбранных компонентов, он не зависает, хотя я только один раз пытался, возможно, будет исследовать более позднее.
Любые мысли с этой дополнительной информацией?
Request info:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729; .NET4.0C)
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 1288
Pragma: no-cache
Cache-Control: no-cache
POST данные
порядок = 842f2988-АБФФ-413С-a092-9dde00a8b9a8 & выбран = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_a1d659c0-b8ec-4f91-ba2f-9d3d01203a4c & выбран = f98c9ad8-49e0 -4a9f-9966-9d3d01203aa5_d6e1984e-227d-4bd0-b8d2-9d3d01203a4d & выбран = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_0b7cbc1a-35f1-4db8-856b-9d3d01203a4c & выбран = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_0cc7ef9b-085f-4b50 -acdb-9d3d01203a4c & selected = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_ad273397-ed5d-49bb-b181-9d3d01203a4c & = выбран f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_b5fbf67f-202f-464B-a9e4-9d3d01203a4c & выбран = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_ae275579-8163-4f6b-9d36-9d3d01203a4c & выбран = f98c9ad8-49e0-4a9f-9966- 9d3d01203aa5_73fa066c-0467-4bc6-aa91-9d3d01203a4c & выбран = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_5020b52f-baa2-4aea-be10-9d3d01203a4d & выбран = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5_8b2cd95a-c014-4c83-9ec6-9d3d01203a4d & selected = f98c9ad8-49e0-4a9f-9966-9d3d01203aa5 & submit = Добавить + To + Suite
Установленный WireShark. Его трудно использовать без прямого управления (удаленный пользователь следует моим командам), но я сразу увидел, что сразу после нажатия submit запрос TCP был отправлен на IP-адрес сервера. Таким образом, браузер выполняет запрос.
Заданный удаленный пользователь для совместной работы с поддержкой IT/сети, чтобы проверить, поступает ли запрос от клиента/прибывает на сервер.
А вот очень похожая проблема, к сожалению, без ответа: https://stackoverflow.com/questions/3355000/my-iis-server-wont-serve-ssl-sites-to-some-browsers
Вот WireShark журнала с сервера. Приступайте к запуску, затем происходит смена шифрования SSL/рукопожатие (через 90 секунд!), После чего после долгого запроса окончательно не выполняется.
No. Time Source Destination Protocol Info
1 0.000000 11.22.33.44 192.168.1.9 TCP [TCP segment of a reassembled PDU]
2 0.000114 11.22.33.44 192.168.1.9 TLSv1 Application Data
3 0.000394 192.168.1.9 11.22.33.44 TCP https > 50950 [ACK] Seq=1 Ack=2305 Win=64690 Len=0
4 97.611245 192.168.1.9 11.22.33.44 TCP https > 50950 [RST, ACK] Seq=1 Ack=2305 Win=0 Len=0
5 97.752530 11.22.33.44 192.168.1.9 TCP 50958 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1459 WS=2 SACK_PERM=1
6 97.752612 192.168.1.9 11.22.33.44 TCP https > 50958 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 SACK_PERM=1
7 97.778024 11.22.33.44 192.168.1.9 TCP 50958 > https [ACK] Seq=1 Ack=1 Win=17508 Len=0
8 97.784462 11.22.33.44 192.168.1.9 TLSv1 Client Hello
9 97.785107 192.168.1.9 11.22.33.44 TLSv1 Server Hello, Change Cipher Spec, Encrypted Handshake Message
10 97.813970 11.22.33.44 192.168.1.9 TLSv1 Change Cipher Spec, Encrypted Handshake Message
11 97.814082 11.22.33.44 192.168.1.9 TLSv1 Application Data
12 97.814208 192.168.1.9 11.22.33.44 TCP https > 50958 [ACK] Seq=123 Ack=2555 Win=64647 Len=0
13 227.535270 192.168.1.9 11.22.33.44 TCP https > 50958 [RST, ACK] Seq=123 Ack=2555 Win=0 Len=0
Вы уже использовали firebug, чтобы увидеть, что вы купили/вернулись? Как насчет прикрепления отладчика к действию, обрабатывающему POST, чтобы узнать, попадаете ли вы в какой-то тип цикла. Используете ли вы сеансы/файлы cookie в методе POST-действия? – Tommy
Я использую файлы cookie, но не «внутри POST», просто на сайте. Конечно, я использую сеансы ASP.NET (формы auth). И я не могу отлаживать ни с помощью Firebug, ни с VS. Я не могу воспроизвести, ошибка является случайной и иногда случается только для очень конкретных пользователей, к которым у меня нет доступа. – queen3
Вы проверили журналы IIS, чтобы узнать, попадает ли запрос на сервер? Также в отношении «пользователей, к которым у меня нет доступа» - это 2010 год, множество технологий, которые могут помочь вам удаленно подключиться к пользователю. Теперь, если вам не разрешено контактировать и взаимодействовать с этими пользователями, это еще одна история, и я не уверен, что это поможет устранить эту проблему. –