Данные HTML-формы утеряны по почте

Question

У нас очень странная проблема, которую нам еще предстоит диагностировать.В нашем приложении есть ряд конкретных действий ASP.NET MVC, которые не выполняются из-за отсутствия обязательного параметра:

The parameters dictionary contains a null entry for parameter 'myVariable' of non-nullable type... etc

Каждый из них является своего рода HTTP POST, и поэтому мы ожидаем увидеть данные формы.В некоторых случаях должно быть более дюжины переменных.

Мы используем ELMAH для сбора ошибок в веб-приложении, и с помощью этого инструмента вы обычно можете видеть фактические данные формы, которые публикуются во время неудачного запроса.Однако в этих конкретных ошибках, когда должно быть несколько переменных, вся форма отсутствует!

Мы просто не можем воспроизвести это по требованию.Однако с объемом трафика в нашем приложении мы видим эти ошибки несколько десятков раз в день.Пользователи также не могут воспроизвести ошибку, и попытка выполнить то же действие в веб-браузере работает второй раз.

Мы также не уверены на 100%, где потеряны данные.Это в веб-браузере?Внутри конвейера IIS?Или это ASP.NET MVC, который его сбрасывает?Совершенно неуверенно.

Если кто-то и может помочь нам в устранении и / или диагностике этой проблемы, это будет очень полезно.

Обновление 1. Мы обнаружили, что длина содержимого указана в заголовках HTTP.имеет размер, который предполагает наличие некоторого содержимого в запросе.Однако коллекция форм по запросу пуста (согласно ELMAH).Поэтому мы добавили некоторые дополнительные средства ведения журнала для отслеживания фактической длины полученного содержимого и самого содержимого.

Обновление 2: мы обнаружили, что хотя HTTP-заголовок CONTENT_LENGTH имеет правильный размер (для аналогичных запросов), сам контент отсутствует.Поток содержит 0 байтов.

Мы также смогли сузить проблему до Internet Explorer, и, похоже, мы не можем этого добиться с другими браузерами.

Нам иногда удавалось воссоздатьпроблема, вызвав несколько перекрывающихся запросов AJAX в браузере, а затем либо обновив, либо перенаправив.Как будто Internet Explorer закрывает соединение перед полной записью потокового буфера.

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

Обновление 3: все, что мы видели, можно объяснить следующим образом: Почему Internet Explorer не отправляет тело сообщения HTTP после вызова Ajax послепровал?

Answer 1

Это может быть немного догадкой, но возможно ли, что ваше действие не имеет ограничения [HttpPost], так что каким-то образом пользователи получают к нему через GET, а не POST?

В моем приложении произошло нечто подобное, когда пользователи пробовали POST для URL-адреса, но срок действия их билета FormsAuthentication истек, поэтому они перенаправляются на страницу входа. Но поскольку странице входа в систему передается параметр «ReturnUrl», после входа в систему они перенаправляются обратно на страницу, на которую они изначально должны отправлять сообщения, но на этот раз с GET. Это может вызвать ошибку, которую вы описываете, поскольку очевидно, что никаких данных POST больше нет. Как я уже сказал, немного догадки ...

Answer 2

Источник проблемы может быть объяснен следующим образом: Почему Internet Explorer не отправляет HTTP-тело сообщения после вызова Ajax после сбоя?

Обновление. Оказывается, что наши специфические симптомы, похоже, связаны с использованием jQuery. После обновления проблема со временем исчезла.

Answer 3

Сообщение об ошибке, которое вы разместили, не похоже на то, что с формой что-то не так.Для меня это похоже на проблему маршрутизации, поэтому вот что я хотел бы спросить:

• Идет ли POST к правильному контроллеру / действию?Например, проверьте, чтобы убедиться, что он идет в правильную область (если вы его используете)
• Соответствует ли сигнатура метода действия контроллера, особенно параметр myVariable, шаблону маршрута?Другими словами, возможно, ваше действие ожидает myVariable, но в URL-адресе, вызывающем его, либо нет myVariable, либо написано с ошибкой и т. Д.