Почему ошибка 404 считается ошибкой на стороне клиента

Что проверяют

Понимаете ли вы, за что отвечает деление кодов на классы 4xx и 5xx, и отличаете ли «ошибка в запросе» от «виноват пользователь». Для тестировщика это ещё и вопрос про то, проверяете ли вы код ответа, а не только картинку на экране.

Как отвечать

Класс 4xx означает, что запрос выполнить нельзя и причина в самом запросе: адрес, метод, заголовки, тело, права. Сервер при этом отработал штатно, он разобрал запрос и осознанно ответил, что ресурса по такому адресу нет. Класс 5xx это обратная ситуация: запрос корректный, сломалась серверная сторона. Слово «клиент» тут про сторону протокола, а не про вину человека: битая ссылка в вёрстке тоже даёт 404, хотя пользователь ничего не вводил.

Что вокруг 404 проверяет тестировщик:

• код реальный, а не 200 с текстом про ненайденную страницу. Такое поисковики считают мягким 404, и это дефект;
• удалённый ресурс отдаёт 404 или 410, но не 500;
• чужой или скрытый объект: 404 вместо 403 иногда выбирают сознательно, чтобы не подтверждать его существование, и это надо сверять с требованиями, а не считать багом;
• тело ответа не раскрывает стек вызовов, путь на диске и версию фреймворка;
• заголовки кэширования: залипший в кэше 404 переживёт починку ссылки.

Где спотыкаются

Отвечают по шаблону ситуация, задача, действие, результат. На вопрос про протокол ждут объяснения механизма, и рассказ о ситуации выглядит как попытка обойти незнание.

Говорят, что 404 значит ошибку пользователя в адресе. Тогда непонятно, почему мониторинг ловит сотни 404 на внутренних ссылках. Точнее так: запрос указывает на несуществующий ресурс, а кто его составил, протоколу неважно.

Путают 404 с 400 и 405. Первый это синтаксически неверный запрос, второй это существующий адрес с неподходящим методом. Если API на DELETE отвечает 404 там, где должен быть 405, это дефект маршрутизации, и находят его только прицельной проверкой методов.