Повний посібник з кодів стану HTTP. Серія 400

Проблеми з клієнтом user-agent можуть бути різними: від запиту ресурсів, яких більше немає (через помилку в URI), до реакції сервера на запити, що відповідають сигнатурі атаки.

Найпоширеніша: 404. 404 Not Found повертається, коли клієнт запитує ресурс, якого веб-сервер не може знайти:

Розгляньмо найпоширеніші й найцікавіші коди відповіді серії 400 трохи детальніше.

400 Bad Request

400 Bad Request (зазвичай) є наслідком того, що user-agent надіслав у запиті щось, чого веб-сервер не зміг обробити. Згенеруймо 400 Bad Request, щоб зрозуміти, що може викликати цю помилку.

Підемо старою школою на Linux і скористаємося інструментом netcat. Netcat можна використати для надсилання сирих даних через сокети. Зрештою, запити HTTP/1.1 і є саме цим: сирим текстом.

Спершу надішлемо коректний запит HEAD до google:

Тепер примусово викличемо 400 Bad Request:

image: src /blog/wp-content/uploads/2017/12/3CEEAuo-e1513087453173.jpg (unchanged); alt: Примусово некоректний запит, що генерує 400

Ми навмисно надіслали запит, якого сервер не зміг зрозуміти. Подивімося на використаний метод запиту:

$ nc www.google.com 80
BAD / HTTP/1,1
Host: www.google.com

Веб-сервер не зміг обробити метод: BAD

Малоймовірно, що сучасний браузер надішле такі некоректні запити, як показано вище. Проте якщо ви використовуєте власноруч розроблений HTTP-застосунок, як-от веб-скрейпер, час налагоджувати.

Ці кроки вирішують більшість поширених помилок 400.

1. Перевірте URL

Якщо ви натиснули посилання, цілком можливо, що автор сторінки припустився помилки. Перевірте весь URL, звертаючи особливу увагу на шлях, назву документа та частину з рядком запиту.

2. Очистьте всі cookies і кеш

Очищення cookies і кешу виправляє багато помилок 400 і є гарним першим кроком і для багатьох інших кодів стану 400.

1. очистьте всі cookies та історію перегляду
2. повторіть запит

У Chrome, Edge і Firefox ця опція міститься в налаштуваннях браузера в розділі приватності й зазвичай називається «Clear browsing data»; назви меню залежать від версії. Часто достатньо очистити cookies лише одного ураженого сайту.

Очищення всіх cookies та історії перегляду гарантує, що все кешоване та/або пошкоджене (як-от cookies) зникне. Це часто виправляє 400 Bad Request.

3. Розмір файлу, що завантажується

Проблема цілком може бути в самому серверному скрипті: завантаження надто великого файлу або файлу з неправильним типом медіа.

1. Якщо 400 bad request виникає під час завантаження файлу, спробуйте менший файл.
2. Переконайтеся, що тип файлу допустимий.
3. Якщо завантажуєте зображення, спробуйте і jpeg, і png.
4. Якщо завантажуєте документ, звичайний текст і поширені офісні формати зазвичай дозволені.

4. Некоректні заголовки

Некоректні заголовки були б доволі низькорівневою проблемою і цілком могли б означати провину самого веб-застосунку.

Інструменти розробника, вбудовані в кожен сучасний браузер (вкладка Network), дають змогу спостерігати всю HTTP-транзакцію й помітити щось незвичне.

5. Оновіть браузер і вимкніть плагіни

Якщо ваш браузер застарів, він цілком може надсилати застарілі заголовки та запити.

Також спробуйте видалити або вимкнути всі плагіни й розширення. Той самий запит в іншому браузері теж допомагає локалізувати проблему.

6. Спробуйте вийти з облікового запису

Якщо ви користуєтеся веб-застосунком з автентифікацією користувачів і сесіями, спробуйте вийти, а потім очистити кеш браузера.

(hr)

401 Unauthorized

401 Unauthorized повертається, коли веб-сервер вимагає облікові дані для захищеного документа.

403 Forbidden

403 Forbidden зазвичай означає одне з чотирьох:

• перегляд вмісту каталогу не дозволений
• поточний автентифікований користувач не має достатніх прав
• процес веб-сервера має недостатні права
• адресу, з якої надійшов запит, заблоковано

Перегляд вмісту каталогу не дозволений

Тут веб-сервер не дозволяє перегляд вмісту каталогу неавтентифікованим користувачам. Найпростіше виправлення: покласти в каталог індексний файл. Інакше перегляд вмісту каталогу для неавтентифікованих користувачів доведеться дозволити явно.

Автентифікований користувач не має прав

Найкращий підхід у цій ситуації: створити групу для всіх користувачів, яким потрібен доступ до ресурсу. Надайте цій групі потрібні права на рівні файлової системи. Потім додайте до групи дозволених користувачів.

Процес веб-сервера не має достатніх прав

image: src /blog/wp-content/uploads/2017/12/XSkGl4h-e1513087253567.jpg (unchanged); alt: Доступ заборонено

Ми не можемо відкрити сторінку test.php у веб-корені /var/www/html. На RHEL і похідних від нього (Oracle Linux, AlmaLinux, Rocky Linux) слід перевірити дві речі: класичні права на файли та контекст SELinux.

Спершу перевірте власника та права:

# ls -ld /var/www/html/
drwx------. 3 root root 4096 Nov 24 03:47 /var/www/html/

Каталог належить користувачеві root і групі root без доступу для будь-кого іншого, тож процес веб-сервера (користувач apache для Apache httpd, nginx для nginx) не може його читати. Надайте групі веб-сервера доступ на читання без запису:

# chgrp -R apache /var/www/html
# chmod 750 /var/www/html
# chmod 640 /var/www/html/test.php
# ls -ld /var/www/html/
drwxr-x---. 3 root apache 4096 Nov 24 03:47 /var/www/html/
# ls -l /var/www/html/test.php
-rw-r-----. 1 root apache 91 Nov 16 06:52 /var/www/html/test.php

Потім перевірте контекст SELinux. Файли, перенесені у веб-корінь звідкись інде, зберігають стару мітку, і тоді SELinux блокує веб-сервер навіть за правильних прав:

# ls -Z /var/www/html/test.php
# restorecon -Rv /var/www/html

Вміст у /var/www/html має нести тип httpd_sys_content_t. Виправте мітку за допомогою restorecon; ніколи не вимикайте SELinux, щоб позбутися 403.

Для безпеки група веб-сервера не повинна мати прав на запис у файли й каталоги. Там, де системі керування вмістом потрібно писати (наприклад, у каталог завантажень), надайте право на запис лише цьому каталогу, а на RHEL призначте йому тип SELinux httpd_sys_rw_content_t.

Заборона прав на запис у файли й каталоги може дати додатковий рівень безпеки на випадок, якщо зловмисник використає вразливість веб-застосунку, щоб змінити вміст, видалити файли або додати нові.

У тестовому середовищі додайте розробників до групи веб-сервера і надайте цій групі право на запис; продакшн тримайте лише для читання.

Ще один поширений сценарій для стану 403 Forbidden: IP-адресу або діапазон IP заблокував адміністратор сервера у файлі .htaccess.

404 Not Found

404 Not Found означає, що веб-сервер не зміг знайти запитаний ресурс. Зустрівши помилку 404, можна зробити кілька речей:

• перевірити написання хоста, домену, шляху та документа
• перевірити регістр файлу та шляху. Веб-сервери Linux і Unix (якщо не налаштовані інакше) зазвичай розрізняють регістр, а за традицією все пишеться малими літерами
• скористатися Google, щоб знайти альтернативний URL ресурсу
• спробувати архівну копію сторінки у Wayback Machine від Internet Archive

Розширені оператори пошуку Google

image: src /blog/wp-content/uploads/2017/12/KbnaNqB-e1513087331180.jpg (unchanged); alt: Google: отримати всі файли PDF

Запит на кшталт показаного вище, з операторами site: і filetype:, часто знаходить документ, старе посилання на який тепер повертає 404.

Якщо сторінку прибрали, Wayback Machine від Internet Archive, можливо, досі зберігає старішу копію.

405 Method Not Allowed

405 Method Not Allowed показується при спробі використати метод запиту, який веб-сервер не дозволяє.

406 Not Acceptable

406 Not Acceptable повертається, коли сервер не може надати ресурс у жодному з типів вмісту, кодувань, мов або наборів символів, які клієнт заявляє прийнятними.

Щоб розв'язати 406, подивіться на заголовки запиту в інструментах розробника вашого браузера (вкладка Network).

Значення заголовків, які надсилає клієнт і які варто перевірити:

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language

Сучасні браузери рідко це викликають. Якщо ваш викликає, спробуйте оновити його до новішої версії.

407 Proxy Authentication Required

407 Proxy Authentication Required зазвичай означає, що user-agent має надати облікові дані для доступу до proxy-сервера.

image: src /blog/wp-content/uploads/2017/12/GpVOCul.jpg (unchanged); alt: Введення облікових даних proxy в Linux

408 Request Timeout

408 означає, що сервер надто довго чекав, поки клієнт закінчить надсилати запит; зазвичай це вказує на повільне або нестабільне з'єднання клієнта, а не на сервер.

429 Too Many Requests

429 зазвичай означає, що на сервері увімкнено обмеження частоти запитів. Обмеження частоти дозволяє лише певну кількість запитів за відведений проміжок часу.

Отримавши 429 Too Many Requests, сповільніться. Сервер може надіслати заголовок Retry-After, який каже, скільки чекати перед повторною спробою; коректні клієнти та скрипти його поважають і відступають.

451 Unavailable for Legal Reasons

451 повертається, коли сервер юридично зобов'язаний заблокувати доступ до ресурсу, наприклад після рішення суду.