Я застрял в выпуске asp.net за последние 2 недели.
Сценарий:
Моя страница приложения имеет 3 элемента управления. Редактор WYSIWYG (свободное текстовое поле), текстовое поле для получения названия редактируемой статьи в редакторе WYSIWYG, другое текстовое поле для ввода ключевых слов.
Порядок элементов управления на странице сверху вниз следующим образом,
во-первых, текстовое поле Имя
во-вторых, WYSIWYG редактор
последнее, текстовое поле ключевого слова
Проблема:
Когда пользователь пытается сохранить отредактированные документы, сервер IIS возвращает время ожидания (производство запускается на win 2008). Но, что интересно, информация о поле «Имя текста» и половина редактора WYSIWYG (не совсем половина, она варьируется для каждого случая) сохраняются в базе данных. но последнее поле с текстом ключевого слова не сохраняется. Во время этого веб-сервер некоторое время зависает, выгоняет пользователя, а через несколько минут возвращается к нормальной скорости. Я думаю, что пул приложений переработан. Но все отлично работает на моей среде разработки (на моем ПК работает на Win 7 64bit). Также я установил ValidateRequest = "False" в директиве страницы для среды производства и разработки.
Окружающая среда:
Среда .NET 4.0, ASP.NET
Редактор текстовых полей WYSIWYG
Общий хостинг 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 недели моего времени, но это был хороший учебный опыт. Спасибо, ребята, за вашу помощь. Очень ценится.