Ошибка 410 Gone: что это такое и как ее исправить

Ошибка 410 Gone – это код состояния ответа HTTP , указывающий, что ресурс, запрошенный клиент был окончательно удален, и клиенту не следует ожидать альтернативного адреса перенаправления или пересылки. Код 410 Gone может показаться похожим на код 404 Not Found , который мы рассматривали несколько месяцев назад, но эти два кода служат совершенно разным целям. Код 404 указывает, что запрошенный ресурс не в настоящее время доступен, но он может быть доступен в будущих запросах. И наоборот, код 410 является явным указанием на то, что запрошенный ресурс использовался , но с тех пор он был окончательно удален и не будет будут доступны в будущем. Таким образом, код ответа 404 указывает, что пользовательский агент (браузер) может повторять запросы к тому же ресурсу URI , в то время как 410 указывает пользовательскому агенту не повторять запросы к тому же самому ресурсу.

Как и большинство кодов ответов HTTP – особенно те, которые указывают на ошибку – появление 410 Gone Error может быть проблемой при правильной диагностике и решении. С потенциальным пулом из более 50 кодов состояния, которые представляют сложные отношения между клиентом, веб-приложением, веб-сервером и часто несколькими сторонними веб-службами, определяя причину конкретной код состояния может быть проблемой даже в самых лучших обстоятельствах.

В этой статье мы рассмотрим 410 Gone Error более подробно, посмотрев, что может вызвать сообщение, а также несколько советов по диагностике и отладке появления этой ошибки в вашем собственном приложении. Мы даже рассмотрим ряд самых популярных систем управления контентом ( CMS ) на предмет потенциальных проблемных областей, которые могут привести к тому, что ваш собственный веб-сайт будет генерировать ошибку 410 Gone Error неожиданно. Давайте углубимся!

На стороне сервера или на стороне клиента?

Все коды состояния ответа HTTP, которые находятся в категории 4xx , являются рассматриваются ответы клиента об ошибках . Эти типы сообщений контрастируют с ошибками в категории 5xx , такими как 504 Gateway Timeout Error , которые мы исследовали некоторое время назад, которые считаются ответы об ошибках сервера . При этом появление ошибки 4xx не обязательно означает, что проблема возникла на стороне клиента, где «клиент» – это веб-браузер или устройство, используемое для доступа к приложению. Часто, если вы пытаетесь диагностировать проблему в собственном приложении, вы можете сразу же игнорировать большую часть клиентского кода и компонентов, таких как HTML, каскадные таблицы стилей (CSS), клиентский JavaScript и т. Д. Это также не относится исключительно к веб-сайтам. Многие приложения для смартфонов с современным пользовательским интерфейсом фактически работают на обычных веб-приложениях за кулисами; тот, который просто скрыт от пользователя.

С другой стороны, это не исключает клиента как фактическую причину Ошибка 410 . Во многих случаях клиент может непреднамеренно отправить запрос не на тот ресурс, что может привести к 410 Gone Error . Мы рассмотрим некоторые из этих сценариев (и возможные решения) ниже, но имейте в виду, что, хотя 410 Gone Error считается ответом на ошибку клиента , это по сути не означает, что мы можем исключить ни клиента, ни сервер как виновников этого сценария. В этих сценариях сервер по-прежнему является сетевым объектом, который создает 410 Gone Error и возвращает его как код ответа HTTP клиенту, но возможно, проблема каким-то образом связана с клиентом.

Начать с тщательного резервного копирования приложения

Как и в любом другом случае, лучше перестраховаться на начало, чем облажаться и пожалеть об этом позже в будущем. Таким образом, критично , чтобы вы выполнили полное резервное копирование вашего приложения, базы данных и т. Д. Перед попыткой каких-либо исправлений или изменений в системе. Еще лучше, если у вас есть такая возможность, создайте полную копию приложения на вторичном промежуточном сервере, который не является «активным» или по другим причинам неактивен и не доступен для всех. Это даст вам чистую площадку для тестирования, на которой можно протестировать все возможные исправления для решения проблемы, не ставя под угрозу безопасность или неприкосновенность вашего действующего приложения.

Диагностика ошибки 410 Gone

Как обсуждалось во введении, ошибка 410 Gone указывает, что пользовательский агент (в большинстве случаев веб-браузер) запросил ресурс, который был окончательно удален из сервер . Это могло произойти при нескольких разных обстоятельствах:

• Сервер имел доступный действительный ресурс в запрошенном месте, но это было намеренно удалено.
• Сервер должен иметь допустимый ресурс в запрошенном месте, но он непреднамеренно сообщает, что ресурс был удален.
• Клиент пытается запросить неверный ресурс.

Устранение неполадок на стороне клиента

Поскольку 410 Gone Error является клиентом код ответа об ошибке , лучше всего начать с устранения любых потенциальных проблем на стороне клиента, которые могут быть причиной этой ошибки. Вот несколько советов, которые можно попробовать в браузере или устройстве, на котором возникают проблемы.

Проверьте запрашиваемый URL

Наиболее частая причина Ошибка 410 Gone просто вводит неверный URL. Как обсуждалось ранее, многие веб-серверы надежно защищены, чтобы запретить доступ к неправильным URL-адресам, к которым сервер не готов предоставить доступ. Это может быть что угодно, от попытки доступа к файловому каталогу через URL-адрес до попытки получить доступ к частной странице, предназначенной для других пользователей. Поскольку коды 410 встречаются не так часто, как коды 404 , появление 410 обычно означает, что запрошенный URL был когда-то действителен, но теперь это не так. В любом случае рекомендуется дважды проверить точный URL-адрес, который возвращает ошибку 410 Gone Error , чтобы убедиться, что это целевой ресурс.

Общая отладка Платформы

Если вы используете общие программные пакеты на сервере, который отвечает 410 Gone Error , вы можете начать с изучения стабильности и функциональность этих платформ в первую очередь. Наиболее распространенные системы управления контентом, такие как WordPress, Joomla! И Drupal, обычно хорошо протестированы сразу после установки, но как только вы начнете вносить изменения в базовые расширения или код PHP ( язык, на котором написаны почти все современные системы управления контентом), слишком легко вызвать непредвиденную проблему, которая приведет к 410 Gone Error .

Ниже приведены несколько советов, которые помогут вам устранить неполадки на некоторых из этих популярных программных платформ.

Откатить последние обновления

Если вы недавно обновляли саму систему управления контентом, незадолго до этого появилась ошибка 410 Gone , вы можете рассмотреть возможность отката к предыдущей версии, которую вы установили, когда все работало нормально. Точно так же любые расширения или модули, которые вы, возможно, недавно обновили, также могут вызвать проблемы на стороне сервера, поэтому возврат к предыдущим версиям также может помочь. Чтобы получить помощь с этой задачей, просто Google «понизьте версию [PLATFORM_NAME]» и следуйте инструкциям. Однако в некоторых случаях некоторые CMS на самом деле не предоставляют возможности понижения версии, что означает, что они считают базовое приложение вместе с каждой новой выпущенной версией чрезвычайно стабильным и свободным от ошибок. Обычно это относится к более популярным платформам, поэтому не бойтесь, если вы не найдете простой способ вернуть платформу к более старой версии..

Удаление новых расширений, модулей или подключаемых модулей

В зависимости от конкретной системы управления контентом, которую использует ваше приложение, точное имя этих компонентов будет другим, но они служат одной и той же цели во всех системах: улучшают возможности и функции платформы сверх того, на что она обычно способна из коробки. Но будьте осторожны: такие расширения могут более или менее полностью контролировать систему и вносить практически любые изменения, будь то код PHP , HTML, CSS, JavaScript или база данных. Таким образом, может быть целесообразно удалить все новые расширения, которые могли быть недавно добавлены. Снова введите в Google имя расширения для официальной документации и помощи в этом процессе.

Проверить на непредвиденные изменения базы данных

Стоит отметить, что даже Если вы удаляете расширение через панель управления CMS, это не гарантирует , что изменения, внесенные расширением, были полностью отменены. Это особенно верно для многих расширений WordPress, которым предоставляется карт-бланш в приложении, включая права полного доступа к базе данных. Если автор расширения явно не кодирует такие вещи, существуют сценарии, в которых расширение может изменять записи базы данных, которые не «принадлежат» самому расширению, а вместо этого создаются и управляются другими расширениями (или даже самой базовой CMS). В этих сценариях расширение может не знать, как отменить изменения в записях базы данных, поэтому оно будет игнорировать такие вещи во время удаления. Диагностировать такие проблемы может быть непросто, но я лично сталкивался с такими сценариями несколько раз, поэтому ваш лучший способ действий, если вы достаточно уверены, что расширение является вероятным виновником 410 Gone Error , заключается в том, чтобы открыть базу данных и вручную просмотреть таблицы и записи, которые, вероятно, были изменены расширением.

Прежде всего, не бойтесь сообщить о своей проблеме в Google. Попробуйте выполнить поиск по конкретным терминам, связанным с вашей проблемой, например по названию CMS вашего приложения, вместе с 410 Gone Error . Скорее всего, вы найдете кого-то, кто столкнулся с той же проблемой.

Устранение неполадок на стороне сервера

Если вы не запускаете приложение CMS – или даже если да, но вы уверены, что 410 Gone Error не связана с этим – вот несколько дополнительных советов, которые помогут вам устранить причину проблемы на стороне сервера вещей.

Подтвердите конфигурацию вашего сервера

Вероятно, ваше приложение работает на сервере, который использует одно из двух самых популярных программных веб-серверов, Apache или nginx . На момент публикации оба этих веб-сервера составляют более 84% мирового программного обеспечения веб-серверов! Таким образом, один из первых шагов, которые вы можете предпринять, чтобы определить, что может быть причиной этих кодов ответа 410 Gone Redirect , – это проверить файлы конфигурации программного обеспечения вашего веб-сервера на предмет непреднамеренных инструкций по перенаправлению.

Чтобы определить, какой веб-сервер использует ваше приложение, вам нужно найти ключевой файл. Если ваш веб-сервер – Apache, поищите файл .htaccess в корневом каталоге файловой системы вашего веб-сайта. Например, если ваше приложение размещено на общем хосте, у вас, скорее всего, будет имя пользователя, связанное с учетной записью хостинга. В таком случае корневой каталог приложения обычно находится по пути /home//public_html/, поэтому файл .htaccess будет быть в /home//public_html/.htaccess .

Если вы нашли файл .htaccess , откройте его в текстовом редакторе и найдите строки, в которых используются директивы RewriteXXX , которые являются частью модуля mod_rewrite в Apache. Подробное описание того, как работают эти правила, выходит далеко за рамки данной статьи, однако основная концепция заключается в том, что директива RewriteCond определяет текстовый шаблон, который будет сопоставляться с введенными URL-адресами. Если соответствующий URL-адрес запрашивается посетителем сайта, директива RewriteRule , следующая за одной или несколькими директивами RewriteCond , используется для выполнения фактического перенаправления запрос на соответствующий URL.

Например, вот простой RewriteRule , который соответствует всем входящим запросам на https://airbrake.io /expired_page и отвечает кодом ошибки 410 Gone Redirect :

  RewriteEngine onRewriteRule ^ (. *) $ https://airbrake.io/expired_page$1 [R = 410, L]  

Обратите внимание на флаг R = 410 в конце RewriteRule , в котором явно указано, что код ответа должен быть 410 , указывая для пользовательских агентов, что ресурс был окончательно удален и не следует делать никаких запросов в будущем. Таким образом, если вы обнаружите какие-либо странные директивы RewriteCond или RewriteRule в файле .htaccess , которые, похоже, не принадлежат попробуйте временно закомментировать их (используя префикс символа # ) и перезапустите веб-сервер, чтобы посмотреть, решит ли это проблему.

С другой стороны, если ваш сервер работает на nginx , вам нужно будет поискать совершенно другой файл конфигурации. По умолчанию этот файл называется nginx.conf и находится в одном из нескольких общих каталогов: /usr/local/nginx/conf , /etc/nginx или /usr/local/etc/nginx . После обнаружения откройте nginx. conf в текстовом редакторе и найдите директивы, использующие флаг кода ответа 410 . Например, вот простая директива блока (то есть именованный набор директив), которая настраивает виртуальный сервер для airbrake.io и гарантирует, что страница ошибки представлен агенту пользователя, который делает запрос 404 Not Found , отправляется на страницу ошибки /deleted.html и получает сообщение 410 Gone ответ с кодом ошибки:

  server {listen 80;  слушайте 443 ssl;  имя_сервера airbrake.io;  error_page 404 = 410/deleted.html;}

Просмотрите файл nginx.conf на предмет аномальных директив или строк, содержащих Флаг 410 . Закомментируйте любые отклонения перед перезапуском сервера, чтобы увидеть, была ли решена проблема.

Параметры конфигурации для каждого типа веб-сервера могут значительно различаться, поэтому мы просто перечислим несколько популярных из них. вам нужно просмотреть некоторые ресурсы в зависимости от того, на каком типе сервера работает ваше приложение:

• Apache
• Nginx
• IIS
• Node.js
• Apache Tomcat

Просмотр журналов

Почти каждое веб-приложение в той или иной форме будет вести журналы на стороне сервера. Журналы приложений обычно представляют собой историю того, что приложение делало, например, какие страницы были запрошены, к каким серверам оно подключалось, какие результаты в базе данных предоставляет и т. д. Журналы сервера связаны с фактическим оборудованием, на котором запущено приложение, и часто предоставляют подробные сведения о работоспособности и статусе всех подключенных служб или даже самого сервера. Google «ведет журнал [PLATFORM_NAME]», если вы используете CMS, или «журналы [PROGRAMMING_LANGUAGE]» и «журналы [OPERATING_SYSTEM]», если вы запускаете собственное приложение, чтобы получить дополнительную информацию о поиске рассматриваемых журналов.

Отладка кода или скриптов приложения

Если все остальное не помогает, возможно, проблема в каком-то настраиваемом коде в вашем приложении. Попытайтесь определить причину возникновения проблемы, отладив приложение вручную и проанализировав журналы приложений и серверов. В идеале сделайте копию всего приложения на локальном компьютере разработки и выполните пошаговый процесс отладки, который позволит вам воссоздать точный сценарий, в котором произошла ошибка 410 Gone . и просмотрите код приложения в тот момент, когда что-то пошло не так.

Независимо от причины – и даже если вам удалось ее исправить на этот раз – появления проблемы, такой как 410 Отсутствие ошибки в вашем собственном приложении – хороший признак того, что вы можете захотеть реализовать инструмент управления ошибками, который поможет вам автоматически обнаруживать ошибки и сообщать о них вам в тот момент, когда они возникают.. Программное обеспечение для мониторинга ошибок Airbrake обеспечивает мониторинг ошибок в реальном времени и автоматическую отчетность об исключениях для всех ваших проектов разработки. Современная веб-панель управления Airbrake гарантирует, что вы будете получать круглосуточную информацию о состоянии вашего приложения и количестве ошибок. Независимо от того, над чем вы работаете, Airbrake легко интегрируется со всеми наиболее популярными языками и фреймворками. Кроме того, Airbrake упрощает настройку параметров исключений, предоставляя вам полный контроль над активной системой фильтрации ошибок, поэтому вы собираете только наиболее важные ошибки.

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