Запрос уходит-уходит, да не приходит

Если бы не

примерно в 20% случаев через минуту-две запрос виден на сервере (в логах IIS), и отрабатывает нормально, в 80% через минуту-две в FireBug видно «Aborted»

можно бы было предположить, что пакет (в какую-то сторону) режется по MTU на каком-то из промежуточных шлюзов.

А на сервере можно просмотреть трафик wireshark'ом или чем-то подобынм? Может в IIS или винде проблема.

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

Прозреваю кривой обработчик форм, который STDIN полностью не вычитывает и начинает кидать ответ.

Так запрос не приходит к IIS-у, а не в обработчик. Ну, это если я правильно понимаю, что в его логах в /LogFiles/W3SVC1 строки вида

2010-08-31 11:52:25 W3SVC1 192.168.56.101 GET /Orders/ - 80 - 192.168.56.1 Mozilla/5.0+(X11;+Linux+i686;+rv:2.0b5pre)+Gecko/20100821+Minefield/4.0b5pre 200 0 0

появляются _ДО_ каких-либо, кривых или нет, обработчиков.

логи - после, ибо в них уже статус ответа (200), надо смотреть до, юзай снифферы

Ах ты ж ёшкин кот вашу медь... туплю.

> Ах ты ж ёшкин кот вашу медь... туплю.

Больше не спорь с людьми, которые имеют такой ник как у меня

Ну раз такой крутой ;-) поясни, что тут происходит на сервере:

Нулевое время - нажатие сабмита, затем через 97, как я понял, почему-то опять обмен любезностями на тему SSL, затем примерно через такое-же время - окончательный фэйл.

Самое интересное, что по HTTP всё работает! В принципе, из лога, как я понял, видно, что фэйлится что-то SSL-ориентированное, но что, я не совсем понял.

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

> Самое интересное, что по HTTP всё работает! В принципе, из лога, как я понял, видно, что фэйлится что-то SSL-ориентированное, но что, я не совсем понял.

Очевидно, причина этого - работа SSL/TLS, моя гипотеза про обработчик оказалась неверна, ибо про SSL в первом посте ничего написано небыло. Очевидно, что вся ошибка кроется в установке сессии, но ничего более сказать не могу, надо поиграть с stonnel и попробовать имитировать сессии.

Насчет stonnel - попробую, хотя wireshark и так вроде умеет декодировать ssl, просто надо ключ запросить.

Нашёл несколько похожих багов, все решаются отключением TLS (в ФФ). Некоторые вызваны багами в JDK, некоторые - багами в OpenSSL... Думаю, здесь тоже какой-то баг.

> Насчет stonnel - попробую, хотя wireshark и так вроде умеет декодировать ssl, просто надо ключ запросить.

Я не про подглядывание, я про эмуляцию запроса из браузера. Есть мнение, что если http-запрос полностью повторить, но инициализацию SSL оставить на другое приложение, то тормозов не будет. Надо это подтвердить или опровергнуть.