1. Причины проблемы
В приложении «Проблемы после релиза» статистики багов после выхода проекта указаны:
В качестве накопления опыта эти проблемы, причины и решения будут включены в чек-лист, а затем:
Первый вопрос: является ли верхний предел параметра URL точной ссылкой? Какова верхняя граница?
Второй вопрос: почему существует ограничение на данные при POST? Лимит — 128K?
2. Анализ проблемы
1. Первое:
1) В URL нет верхнего предела параметров. Проблема в том, что в IE есть ограничение по длине URL.
2) Спецификация протокола HTTP также не ограничивает длину URL. Это ограничение — это ограничение, наложенное конкретным браузером и сервером. Ограничение по длине URL в IE составляет 2083 байта (2K+35). Для других браузеров, таких как Netscape, Firefox и др., теоретического ограничения по длине нет, и он зависит от поддержки операционной системы. [Ссылка 1]
3) «Параметры переменной длины передаются через URL» на самом деле означает, что при подаче формы используется метод GET, а не метод POST. Причиной этой потенциальной ошибки является использование метода GET для подачи данных форм. Потому что метод GET передаёт данные по URL серверу для обработки.
4) Обратите внимание, что это ограничение — это вся длина URL, а не только длина данных параметра.
5) Поскольку это ограничение по длине URL в IE, и метод GET, и метод POST имеют это ограничение.
(Пожалуйста, обратитесь к соответствующему документу для получения информации о методах GET и POST в ФОРМЕ [Ссылка 2])
Рекомендации:
1) Понять среду, в которой расположено приложение, например, браузер и серверную среду веб-приложения, и понять её специфические ограничения параметров.
2) Максимально используйте метод POST для подачи сложных данных. Примечание: Когда FORM не записывает атрибут метода, по умолчанию используется метод GET.
Заключение (записать в чек-лист):
При подаче данных с помощью метода GET необходимо учитывать ограничение длины URL в 2083 байта в среде IE.
2. Второе:
1) Теоретически у POST нет ограничения по размеру. Спецификация протокола HTTP также не имеет ограничений по размеру.
2) «Существует ограничение размера 128K для POST-данных» недостаточно точно, нет ограничений для POST-данных, а вычислительная мощность процессора сервера играет ограниченную роль.
3) Для программ ASP существует ограничение длины данных в 100К, когда объект Запрос обрабатывает каждое поле формы. Но с Request.BinaryRead такого ограничения нет. Для решений, требующих обработки более 100 тысяч данных домена формы, пожалуйста, обратитесь к [Ссылке 3] ниже.
4) В пространстве, для IIS 6.0 Microsoft ужесточила ограничения по соображениям безопасности [Ссылка 4]. Также нужно обратить внимание на:
IIS 6.0 по умолчанию содержит максимум 200 КБ данных ASP POST, а лимит — 100 КБ на поле формы.
Размер файлов для загрузки IIS 6.0 по умолчанию составляет 4 МБ.
IIS 6.0 по умолчанию имеет максимальный заголовок запроса 16 КБ.
Эти ограничения не были доступны до IIS 6.0.
Рекомендации:
1) Знание стандартных настроек рабочей среды поможет вам проектировать и быстро решать возникающие проблемы.
2) Следует рассмотреть версию сервера. Каждая версия IIS имеет свои настройки по умолчанию для этих параметров, поэтому при необходимости найдите информацию и составьте таблицу сравнения. Таким образом, есть справочник для разработки и тестирования.
3) Эти ограничения IIS 6.0 на самом деле являются её стандартными настройками, и вы можете изменить их в реальной среде приложения.
В WINNT/system32/inetsrv/MetaBase.xml определение по умолчанию звучит так:
AspBufferingLimit="4194304" соответствует максимальному размеру загруженного файла
AspMaxRequestEntityAllowed="204800" соответствует максимальному объёму данных в POST
...
Заключение (записать в чек-лист):
При использовании ASP нужно учитывать, что форма POST имеет ограничение 100 КБ на поле для общей обработки чтения. Подумайте, стоит ли использовать Request.Binary.
|
Опубликовано 08.03.2018 10:18:07
|
|
|
|
