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) Оскільки це обмеження IE на довжину URL, і метод GET, і метод POST мають це обмеження.
(Будь ласка, зверніться до відповідного документа для отримання деталей про методи GET і POST у формі [Ref. 2])
Рекомендації:
1) Зрозуміти середовище, в якому розташований додаток, наприклад, браузерне та серверне середовище веб-додатку, а також зрозуміти його конкретні обмеження параметрів.
2) Максимально використовуйте метод POST для подачі складних даних. Примітка: Коли FORM не записує атрибут методу, за замовчуванням використовується метод GET.
Висновок (записати до Checklist):
При подачі даних за методом GET потрібно враховувати обмеження довжини URL у 2083 байти в IE-середовищі.
2. Другий:
1) Теоретично POST не має обмежень по розміру. Специфікація протоколу HTTP також не має обмеження за розміром.
2) «Існує обмеження розміру 128K для POST-даних» недостатньо точно, немає обмежень для POST-даних, а обчислювальна потужність процесора сервера відіграє обмежувальну роль.
3) Для ASP-програм існує обмеження довжини даних у 100К, коли об'єкт Запит обробляє кожне поле форми. Але з Request.BinaryRead такого обмеження немає. Для рішень, що потребують обробки понад 100K даних домену форми, будь ласка, зверніться до [Посилання 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
...
Висновок (записати до Checklist):
При використанні ASP потрібно враховувати, що форма POST має обмеження 100 КБ на поле для загальної обробки читання. Розгляньте, чи варто використовувати Request.Binary.
|
Опубліковано 08.03.2018 10:18:07
|
|
|
|
