трял в выпуске asp.net за последние 2 недели.

Сценарий:

Моя страница приложения имеет 3 элемента управления. WYSIWYG-редактор (Free Textbox), текстовое поле для получения названия редактируемой статьи в WYSIWYG-редакторе, другое текстовое поле для ввода ключевых слов.

Порядок элементов управления на странице сверху вниз следующим образом,
во-первых, текстовое поле Имя
во-вторых, WYSIWYG редактор
последнее, текстовое поле Key Word

Проблема:

Когда пользователь пытается сохранить отредактированные документы, сервер IIS возвращает время ожидания (производство работает на win 2008). Но, что интересно, информация о поле «Имя текста» и половина редактора WYSIWYG (не совсем половина, она варьируется для каждого случая) сохраняются в базе данных. но последнее поле с текстом ключевого слова не сохраняется. Во время этого веб-сервер некоторое время зависает, выгоняет пользователя, а через несколько минут возвращается к нормальной скорости. Я думаю, что пул приложений переработан. Но все отлично работает на моей среде разработки (на моем ПК работает на Win 7 64bit). Также я установил ValidateRequest = "False" в директиве страницы для среды производства и разработки.

Окружающая обстановка:

Среда .NET 4.0, ASP.NET
WYSIWYG-редактор FreeText box
Общий хостинг Windows 2008
SQL Server 2008

Испытанные решения (но без прорыва):

Пробовал с другим браузером Firefox, Chrome, IE и той же ошибкой.
Добавил ValidateRequest = "False" в директиву страницы и заменил WYSIWYG-редактор обычным текстовым полем и попытался сохранить ту же проблему.
Просто попытался записать данные поста прямо из объекта page.request. Все еще получаю полные данные для «Текстового поля имени», половину для текстового поля WYSIWYG и ничего для отдыха.
Нет проблем с подключением к БД или полем таблицы. Я трижды проверил.

Возможные подозрения и вопросы:

Насколько мне известно, нет никаких ограничений на длину данных поста. но в IIS это можно переопределить? интересно, установлено ли это на моем общем хостинге.
В основном данные постов http усекаются где-то между браузером и объектом server.request. Какова будет причина, если это происходит?
Если http-сообщение урезано, почему все приложение зависает (или перезапускается)?
Какие меры предосторожности необходимо предпринять при публикации HTML-контента в виде http-сообщения?

Спасибо.

Новая находка:

Проверил мой пост, используя httpfox. Размер сообщения составлял около 9958 байт. Но Firefox отправляет сначала 330 байт данных, а затем веб-страница зависает. Примерно через минуту я получаю код ошибки NS_ERROR_NET_RESET в httpfox.

Проверил мой пост, используя filder2 с IE9. Он пытается отправить первые 512 байт, а затем зависает. Возвращает «ReadResponse () не удалось: сервер не возвратил ответ на этот запрос».

Вопрос:

Скорее всего, это проблема браузера или сервера. Я думаю, что если проблема с браузером, это не произойдет для IE и Firefox.

Обновить:

Скорее всего, изолированы проблемы с веб-хостинга. Протестировано путем изменения URL-адреса почтовой формы для другого домена и проверки возможности получения значений в этом домене. Да, это работает. Только это не сработало для моего домена. Интересно, что я проверил это для нормального поста HTML-страницы это также не сработало. Так что, скорее всего, установлена ​​безопасность, чтобы предотвратить эту или неправильную настройку сервера. Уже положил билет на них и жду.

Любое, как вся ваша обратная связь помогла мне изолировать проблему.

Решено:

Да, эта проблема была на нашем веб-хостинге. До сих пор я слышал от них, что какой-то брандмауэр блокирует большой пост от http. Они сказали, что теперь наш домен находится в белом списке. Во всяком случае, теперь это работает. Но это съело 2 недели моего времени, но это был хороший учебный опыт. Спасибо, ребята, за вашу помощь. Очень ценится