Http error 422 как исправить

HTTP error 422 is not as common as other codes such as 404 or 500. This particular error can be hard to diagnose as it doesn’t provide you with much information about what part of your request is causing the problem.

Broadly speaking, if you see an HTTP 422 error it means the server understands your request, but it can’t fulfill it due to a problem on your end. If you fix that problem, you should be able to reload the page and the error will go away.

In this article, we’ll talk about what causes the 422 error and how to troubleshoot it if you’re using WordPress. Let’s get to it!

Check Out Our Video Guide to the 422 Error

What Is the HTTP 422 Error?

Error 422 is an HTTP code that tells you that the server can’t process your request, although it understands it. The full name of the error code is 422 “unprocessable entity.”

In a nutshell, the error means that you’re making a request the server understands, but it can’t process it. Typically, this happens because there’s a semantic error somewhere in the request, usually within a PHP or JavaScript file.

Unlike other HTTP errors, the 422 code will keep reappearing until you manage to troubleshoot the problem with your request. However, this can be difficult since the error doesn’t provide specific information about what part of the request it can’t process.

What Causes the HTTP 422 Error?

Typically, the HTTP 422 code pops up when there’s a semantic error in the contents of a request. If you’re using WordPress, that usually means one of two things:

  1. One of the files involved in the request contains code with semantic errors. To put it another way, there’s an error somewhere in the code.
  2. You’re dealing with a corrupt database table.

One problem with error 422 is that there’s no way of knowing what its cause is at first glance. This means you may need to try more than one troubleshooting method until you arrive at the problem.

HTTP error 422 may not be as common as other codes such as 404 or 500- but don’t worry! 😅This guide is here to help 🚀Click to Tweet

You can check the HTTP response code of any page using our HTTP header Checker tool.

How To Fix the 422 Error in WordPress (2 Methods)

In this section, we’ll show you how to repair a corrupted WordPress database and how to identify files with semantic code errors. These steps will also help you debug other issues, such as the HTTP 400 error.

1. Repair a Corrupted WordPress Database

In some cases, tables within the WordPress database might become corrupted during an update. This means that if you’re updating a plugin, theme, or WordPress itself and the process is interrupted, database entries can start presenting errors.

A corrupt database can lead to all sorts of errors within WordPress, such as pages not loading, features not working correctly, and HTTP codes such as 422. There are two ways to repair a corrupted WordPress database. The easiest approach is to use a plugin such as WP-DBManager:

WP-DBManager plugin

WP-DBManager

Once you activate WP-DBManager, you’ll get access to a new Database tab in the dashboard. Go to Database > Repair DB and select the tables that you want to repair. Since you may not know which table is corrupt, select them all and click on Repair:

Repair database tab

Find the Repair DB tab

The process should only take a few seconds and you’ll see a success message when it’s ready. Now, try accessing the page that returned the 422 error to see if it persists.

If you don’t have access to the WordPress admin due to the 422 error, you can repair the database manually. To do so, you’ll need to access the database from your hosting control panel.

If you use Kinsta, you can access the database from your MyKinsta dashboard. Select a website and go to the Info tab. Look for the Database access section, where you’ll find the login credentials for the database. Click on Open phpMyAdmin and enter those credentials:

Login to phpMyAdmin

phpMyAdmin

Select the database you want to repair from the menu to the left and you’ll see a breakdown of all the tables it contains to the right. Use the Check all option at the bottom of the page to select every table. Then, look for the Repair table option in the menu to the right:

Find the repair table option

Repair table option

Click on the Go button and wait for phpMyAdmin to return a success message. Now, go ahead and check if the HTTP 422 error persists.

2. Use the WordPress Error Logs To Identify HTTP 422 Code Causes

If repairing the database doesn’t make error 422 go away, the problem lies with one of the WordPress files. Since every WordPress installation contains dozens to hundreds of files, it’s not feasible to check all of them for semantic code errors.

Your best bet, in this scenario, is to enable the WordPress debug feature, which will give you access to error logs. To enable the WordPress debug mode manually, you’ll need to edit the wp-config.php file in the root directory.

You can do that by accessing your website via a File Transfer Protocol (FTP) client and locating the wp-config.php file. Open the file and add the following two lines of code before the line that says /* That’s all, stop editing! Happy blogging. */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );

If the WP_DEBUG line already exists, make sure that it reads true and simply add the second line of code (the WP_DEBUG_LOG entry). Save the changes to the file and reload the page that returns the 422 error.

The error should persist, but now you have access to error logs. To read those logs, navigate to the wp-content folder inside the root directory and look for the debug.log file. You can open the file using a text editor.

If the file is new, it should only contain a few lines, one of which should refer to the error that’s causing the 422 code. The error should point you towards a specific file that’s causing the problem. It should also include information about which line within the file contains a semantic error.

If you use Kinsta, you don’t have to enable the WordPress debug mode or error logs manually. Instead, go to MyKinsta, select a website, and jump to the Tools tab. Inside you’ll find an option for enabling WordPress debugging:

WordPress debugging in MyKinsta

WordPress debugging in MyKinsta

After enabling debugging, you can go to the Logs tab and select the error.log option. MyKinsta will display the latest errors on your website and the viewer includes a search feature to help you find specific entries:

MyKinsta will display errors

Errors will display in MyKinsta

Focusing on the latest entries should help you identify which file is causing the 422 error. Once you identify the file, you can try and fix the semantic error or replace it with a stock version from WordPress.

Learn what causes what 422 error and how to troubleshoot it if you’re using WordPress, all in this guide 😄Click to Tweet

Summary

Identifying what’s causing the HTTP 422 error can be somewhat complicated. However, troubleshooting the error doesn’t take all that long. The process is much simpler if you’re using WordPress, as the software comes with tools that can help you when it comes to debugging errors.

If you run into the HTTP 422 error in WordPress, there are two ways that you can fix it:

  1. Repair a corrupted WordPress database.
  2. Use the WordPress error logs to identify the causes of the 422 code.

With Kinsta, troubleshooting errors is much easier. Our MyKinsta dashboard includes built-in tools for debugging WordPress. If you don’t want to troubleshoot issues manually, you can always reach out to our support team!


Get all your applications, databases and WordPress sites online and under one roof. Our feature-packed, high-performance cloud platform includes:

  • Easy setup and management in the MyKinsta dashboard
  • 24/7 expert support
  • The best Google Cloud Platform hardware and network, powered by Kubernetes for maximum scalability
  • An enterprise-level Cloudflare integration for speed and security
  • Global audience reach with up to 35 data centers and 275 PoPs worldwide

Get started with a free trial of our Application Hosting or Database Hosting. Explore our plans or talk to sales to find your best fit.

Ошибка 422: решение

Код состояния 422 (HTTP 422 Unprocessable Entity) обозначает ошибку со стороны пользователя, а не API. Сервер понимает запрос со стороны клиента и может работать с типом содержимого, который ему предоставили. Однако логическая ошибка делает выполнение невозможным.

Например, документ XML построен синтаксически грамотно, но со стороны семантики в инструкции содержится погрешность.

  • вы отправляете полезные данные, которые недействительны в формате JSON;
  • вы отправляете заголовки HTTP, такие как Content-Type или Accept, которые указывают значение, отличное от application / json;
  • запрос может быть валиден по отношению к JSON, но что-то не так с содержимым. Например, указание API обновить кластер до несуществующего варианта;
  • в теле или запросе содержится лишний символ или пробел (в первую очередь стоит проверить пробелы перед заголовком) или напротив, не хватает кавычек/проставлен неправильный тип. Самая актуальная проблема при работе с JSON, при которой может перестать работать весь код.

Проблема ошибка 422 через Ajax Post с использованием Laravel

В ajax этот код может выдаваться как ошибка по умолчанию, когда проверка не выполняется. Либо возвращаться Laravel при запросе, в котором допущена опечатка. Можно попробовать сделать запрос в консоли браузера: он должен выдать JSON с ошибками, возникшими во время проверки запроса. Есть вероятность, что код просто отправляет атрибуты формы не так, как вы запланировали. В любом случае, проблему решать программисту или вебмастеру.

Дополнительная информация

К сожалению, дать универсальный совет по исправлению ошибки 422 Unprocessable Entity непросто. Путь разрешения может сильно отличаться для каждой частной ситуации.

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

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

Дальше по теме…

Содержание

  1. Support
  2. 422 Unprocessable Entity Explained
  3. What is 422 Unprocessable Entity ?
  4. 400 vs 422 status codes
  5. How to fix a 422 Unprocessable Entity error?
  6. Summary
  7. What Is HTTP 422 And Why You Should Use It?
  8. Published by Paweł Pluta on 2020-03-23 2020-03-23
  9. The need for proper status
  10. Word on Client Error codes
  11. Doubts about 422
  12. So, why we decided to utilise it?
  13. Can the response be more descriptive?
  14. Security consideration
  15. Hiding what should not be visible
  16. Design API responsibly
  17. Ошибка 422: Суть проблемы и пути решения
  18. Самые частые причины возникновения ошибки 422:
  19. Проблема ошибка 422 через Ajax Post с использованием Laravel
  20. Дополнительная информация
  21. Коды ошибок HTTP: полный список ошибок сервера
  22. Ошибки со стороны клиента (4xx)
  23. 400 Bad Request
  24. 401 Unauthorized
  25. 402 Payment Required
  26. 403 Forbidden
  27. 404 Not Found
  28. 405 Method Not Allowed
  29. 406 Not Acceptable
  30. 407 Proxy Authentication Required
  31. 408 Request Timeout
  32. 409 Conflict
  33. 410 Gone
  34. 411 Length Required
  35. 412 Precondition Failed
  36. 413 Payload Too Large/Request Entity Too Large
  37. 414 URI Too Long
  38. 415 Unsupported Media Type
  39. 416 Range Not Satisfiable
  40. 417 Expectation Failed
  41. 418 I’m a teapot
  42. 421 Misdirected Request
  43. 422 Unprocessable Entity
  44. 423 Locked
  45. 424 Failed Dependency
  46. 425 Too Early
  47. 426 Upgrade Required
  48. 428 Precondition Required
  49. 429 Too Many Requests
  50. 431 Request Header Fields Too Large
  51. 444 No Response
  52. 449 Retry With
  53. 450 Blocked by Windows Parental Controls
  54. 451 Unavailable For Legal Reasons

Support

Find answers, guides, and tutorials to supercharge your content delivery.

422 Unprocessable Entity Explained

What is 422 Unprocessable Entity ?

A 422 status code occurs when a request is well-formed, however, due to semantic errors it is unable to be processed. This HTTP status was introduced in RFC 4918 and is more specifically geared toward HTTP extensions for Web Distributed Authoring and Versioning (WebDAV).

There is some controversy out there on whether or not developers should return a 400 vs 422 error to clients (more on the differences between both statuses below). However, in most cases, it is agreed upon that the 422 status should only be returned if you support WebDAV capabilities.

A word-for-word definition of the 422 status code taken from section 11.2 in RFC 4918 can be read below.

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415 (Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions.

The definition goes on to say:

For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

400 vs 422 status codes

Bad request errors make use of the 400 status code and should be returned to the client if the request syntax is malformed, contains invalid request message framing, or has deceptive request routing. This status code may seem pretty similar to the 422 Unprocessable Entity status, however, one small piece of information that distinguishes them is the fact that the syntax of a request entity for a 422 error is correct whereas the syntax of a request that generates a 400 error is incorrect.

The use of the 422 status should be reserved only for very particular use-cases. In most other cases where a client error has occurred due to malformed syntax, the 400 Bad Request status should be used.

How to fix a 422 Unprocessable Entity error?

To fix a 422 Unprocessable Entity error isn’t so cut and dry. The resolution path can very much differ for each scenario. However, as described above in the RFC definition of the 422 status, the error occurs when your data is incorrect; or for the lack of better terms, doesn’t make logical sense.

Try reviewing your data to verify whether or not you may have incorrectly defined a particular piece of data in your request. If you’re still unable to find out the issue, try asking around in a web development community (e.g. Stackoverflow) with an example snippet of your code to see whether or not others can pinpoint where the issue is.

Summary

In conclusion, the 422 status code isn’t overly common anymore. As of RFC 7231, the 400 Bad Request status code has gathered good traction and in most cases is used as a replacement to the 422 status. Although, if you have a very specific use-case where you are making use of WebDAV and need to return a status code for a request that was syntactically correct but semantically incorrect then you could make use of the 422 status code under those circumstances.

Источник

What Is HTTP 422 And Why You Should Use It?

Published by Paweł Pluta on 2020-03-23 2020-03-23

Selecting a proper HTTP Response Code makes REST API more descriptive. However, developers are lazy. While reviewing a REST API, I’ve seen a lot of cases, that the only response codes returned were HTTP 500 (aka “backend is not working”) and 400 (broadly known as “frontend messed up”). “Better” APIs were also returning 404 and authentication/authorization failure codes, but still, they should not be named as RESTFull. Such an approach is fast to implement and covers most of the use cases. But have you ever wonder, what will happen if developers have the possibility and time to experiment? They will delve into it.

This article has to make you pay attention to the quality of messages returned by your API, with the biggest focus on 422 Unprocessable Entity status codes. Selecting response codes carefully will make your API more descriptive and easier to use, reducing feedback loop time needed for root cause analysis.

The need for proper status

One day in my work, we were implementing some API, that was consuming JSON. Nothing special, but there was some logic behind two fields sent in a message payload.

curl for sample command invocation.

Generally, the time difference between dates could not be bigger than some period. Tests, that we wrote for this endpoint, were checking if HTTP 400 Bad Request was returned in case of the too broad time range. Looked solid, but during code review, we got a comment, if is this a good status code, as request syntax is perfectly valid, but semantics is here a problem. Well, that started a very long discussion.

Word on Client Error codes

In general, response codes classes start with very broad information. For Client Error codes it is HTTP 400 Bad request, originally meaning “request sent by client has a malformed syntax”, which was very strict about the reason behind this status. Later, in updating RFC 7231, the definition of 400 was defined less restrictive. Since 2014, it is just information about potential client problem, that sent an invalid request. Neither specific nor descriptive. Hopefully, there are a lot of other status codes, that could be used.

Looking on a list published on IANA or Mozilla Developer Center, we can see that they are more and more specific, from authorization issues, through invalid header values, to legal problems, so probably there is an error code that will fit our needs. In our case, we got a suggestion that 422 Unprocessable Entity could be used.

Doubts about 422

Request that we sent was perfectly fine in the matter of syntax, as the content type was understood by the server, and its body was successfully parsed. The problem was just in data that was provided within the body, which made our case a perfect situation for Unprocessable Entity status. Such a situation might happen for some reasons, e.g. because of logic behind command processing, like a requirement that selected period cannot be bigger than 60 days. That could be achieved by changing userRegisteredTo field value to out of the defined range.

In this case, requested command contained date range for over 60 days.

Even if requested command syntax was correct, data inside it was not. It can also happen in other scenarios, that check the quality of provided data, like in one below, where a user wants to set prices for shipping packages to some country but is trying to use the currency that cannot be used within it:

Imagine, that system that you are developing allows for paying in euro and some cryptocurrency in Germany, but not in United States dollars.

Even if our cases looked like a perfect match for 422 status code, we still had concerns regarding if it should be used. It is not a part of the standard HTTP protocol but is a part of its extension called WebDAV. WebDAV is used for managing resources, usually files, directories, and its properties. As we were not implementing anything related to WebDAV, it looked like an overhead. We were going to use only one response code defined in whole, over 120 pages documentation. We liked the response code, but we needed proof that we can use it.

So, why we decided to utilise it?

To get an argument for using code from extension to plain HTTP, we need to take a step back and check original documentation one more time. Fortunately, in a section that is describing status codes there is one, very important sentence for us:

This opens a lot of doors for using available extensions. There is a huge benefit in using specific response codes, as it provides information about the root cause of the problem. Knowing what was wrong, API clients can perform retry, tell users to fix the data, or authorize again, depending on retrieved status. It could not be possible with returning general HTTP 400 Bad Request in response.

Can the response be more descriptive?

Take the benefit of various response code, and inform clients about the source of a problem. If no code will match your need, remember that HTTP statuses are extensible, so look for best one also within extensions, or as a last resort — create your own one. If that is not enough for your case, consider implementing Problem Details for your API. Problem details can give huge insight for a user that is using your API, e.g. when requested setting price for shipping in invalid currency, apart from status code, it could provide response body like:

Format of response is standardized, if you are interested in it, please refer to the documentation.

Security consideration

Descriptive responses from your API may accidentally expose valuable information for attackers. You should not expose information about your infrastructure (webserver implementation, database version), or used language and its version. Make sure to never return any stack trace within your response body. All this information can allow malicious users to use exploits and break your application. You can also perform some additional steps to protect yourself, as not always returning detail is desirable behaviour.

Photo by ÉMILE SÉGUIN 🇨🇦 on Unsplash

Hiding what should not be visible

One of the things, that can improve your API security, is hiding details from a user that do not have access to a resource. Let’s visualize it with resource providing business deal details under /api/contracts/32167 . Who should be able to see those details? Probably only allowed users. Even more, probably not allowed users should even not know if such resource exists. Therefore, if an unauthorized user A would request for this contract details, it could get a response 404 Not Found (instead of 403 Forbidden), which will hide from him even existence of such agreement.

A similar situation should happen for a user that is not logged in. Instead of returning 403 Forbidden for protected resources and 404 Not Found for not existing ones, it might be valuable to return 401 Unauthorized for all non-public resources. Usually, users, who are not authorized, are not consumers of API, so they should not retrieve detailed reasons.

Design API responsibly

Meaningful responses are simplifying communication, leaving no room for guesses that may lead to long hours for analysing the root cause. Being strict and precise in HTTP responses will cause your API more discoverable and easier to use for your clients. Just make sure, that you will not tell them too much.

Источник

Ошибка 422: Суть проблемы и пути решения

Код состояния 422 (HTTP 422 Unprocessable Entity) обозначает ошибку со стороны пользователя, а не API. Сервер понимает запрос со стороны клиента и может работать с типом содержимого, который ему предоставили. Однако логическая ошибка делает выполнение невозможным.

Самые частые причины возникновения ошибки 422:

  • вы отправляете полезные данные, которые недействительны в формате JSON;
  • вы отправляете заголовки HTTP, такие как Content-Type или Accept, которые указывают значение, отличное от application / json;
  • запрос может быть валиден по отношению к JSON, но что-то не так с содержимым. Например, указание API обновить кластер до несуществующего варианта;
  • в теле или запросе содержится лишний символ или пробел (в первую очередь стоит проверить пробелы перед заголовком) или напротив, не хватает кавычек/проставлен неправильный тип. Самая актуальная проблема при работе с JSON, при которой может перестать работать весь код.

Проблема ошибка 422 через Ajax Post с использованием Laravel

В ajax этот код может выдаваться как ошибка по умолчанию, когда проверка не выполняется. Либо возвращаться Laravel при запросе, в котором допущена опечатка. Можно попробовать сделать запрос в консоли браузера: он должен выдать JSON с ошибками, возникшими во время проверки запроса. Есть вероятность, что код просто отправляет атрибуты формы не так, как вы запланировали. В любом случае, проблему решать программисту или вебмастеру.

Дополнительная информация

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

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

Источник

Коды ошибок HTTP: полный список ошибок сервера

Умные люди придумали коды, по которым можно определить, что произошло с HTTP-запросом. Успешен ли он, произошло ли перенаправление. Или же все закончилось ошибкой. Как раз об ошибках и будем говорить в этой статье. Вкратце расскажу, какие они бывают и с чем связаны.

А еще тут будет парочка забавных (и не очень) пикч и анимаций на тему описанных ошибок. Хоть какое-то развлечение.

Ошибки со стороны клиента (4xx)

Для начала перечислим коды ошибок на стороне клиента. Вина за их появление ложится на плечи обоих участников соединения.

400 Bad Request

Такой ответ от браузера можно получить в том случае, если сервер не смог правильно отреагировать на запрос со стороны пользователя. Часто код 400 возникает при попытке клиента получить доступ к серверу без соблюдения правил оформления синтаксиса протокола передачи гипертекста (HTTP). Повторный запрос не стоит отправлять до тех пор, пока не будет исправлена ошибка (или несколько из них).

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

402 Payment Required

Эта ошибка сообщает клиенту о том, что для успешного выполнения запроса ему необходимо оплатить доступ к серверу. Изначально код 402 должен был стать неким стандартом для цифровой валюты и оплаты контента в сети. Но не срослось. До сих пор нет единого решения по поводу того, как должны выглядеть платежи в сети. Также нет и единого решения по поводу того, как стоит использовать 402.

Все еще считается, что код существует с расчетом на будущее. Сейчас почти не используется и поддерживается не всеми браузерами.

403 Forbidden

Почти то же, что и 401. Сервер снова не разрешает к нему подключиться, хотя с запросом все в порядке. Просто нет доступа. Причем повторная авторизация с другими логином и паролем никак не помогут. Все вопросы к владельцам сервера (но не всегда). Инструкция по устранению ошибки.

Творчество на тему знаменитой киносаги

404 Not Found

Легендарная ошибка, ставшая популярным мемом. 404 оповещает клиента о том, что его запрос ведет в никуда. Код возникает, когда пользователь пытается попасть на страницу, которой не существует. Например, когда случайно ошибается при вводе ссылки и вводит ее с опечаткой. Или же пытается получить доступ к странице, которой на сайте уже нет.

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

И таких вариаций тысячи. Каждый пытается добавить в оформление что-то свое.

405 Method Not Allowed

405 сообщает клиенту о том, что метод, используемый при запросе, не разрешен. В качестве примера можно привести попытку со стороны клиента ввести данные в форму с помощью GET, когда она работает только с POST. Ну и в таком же духе.

406 Not Acceptable

Ошибка 406 сообщает о том, что страница передает контент, который не может быть распознан клиентом. Возможно, проблема в методе сжатия или в формате страницы. Иногда сюда же приплетают неправильные настройки кодировки.

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

407 Proxy Authentication Required

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

408 Request Timeout

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

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

В Мистере Роботе частенько называли серии в честь ошибок HTTP (весь четвертый сезон в нумерации 4хх). В честь 408, например, назвали восьмую серию четвертого сезона

409 Conflict

Сообщение о конфликте возникает, когда запрос со стороны клиента не соответствует тому, чего ожидает сервер. В качестве примера приводят проблемы при проверки версий, когда пользователь пытается с помощью метода PUT загрузить на сервер новый файл, но там уже имеется более новая версия того же файла. Конфликта версий можно легко избежать, загрузив корректную версию.

410 Gone

Своего рода аналог 404. Разница лишь в том, что 410 намекает на перманентность отсутствия страницы. Так что этот код стоит использовать, когда на 100% уверен, что страница ушла в небытие (ну или с текущего адреса) навсегда. В любом другом случае есть универсальный 404.

411 Length Required

411 оповещает пользователя о том, что сервер не желает принимать запрос со стороны клиента, потому что в нем не определен заголовок Content-Length. Да, это первый код в подборке, который смогут понять только люди, сведущие в настройке серверов. По-простому уложить сущность HTML-заголовков в этот материал не получится.

412 Precondition Failed

Еще один код, сообщающий о том, что сервер отклонил запрос пользователя и не разрешает доступ к выбранному ресурсу. Проблемы возникают при неправильной настройке работы методов, отличающихся от GET и HEAD.

413 Payload Too Large/Request Entity Too Large

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

414 URI Too Long

Чем-то этот код похож на предыдущий. Здесь тоже идет речь о превышение лимита. Только теперь это касается не запроса со стороны клиента, а длины URI. То есть ссылки. Выходит, что адрес, используемый клиентом, больше, чем тот, что может обработать сервер. Как-то так.

Такая ошибка иногда выскакивает при попытке взломать ресурс. Сайт так реагирует на слишком частые попытки воспользоваться потенциальными дырами в безопасности.

415 Unsupported Media Type

Ошибка 415 возникает, когда клиент пытается загрузить на сервер данные в неподходящем формате. В таком случае сервер просто отказывается принимать посылаемые файлы и разрывает соединение. Как и в случае с 413.

416 Range Not Satisfiable

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

417 Expectation Failed

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

418 I’m a teapot

Код 418 можно увидеть, если сервер откажется варить кофе, потому что он чайник. Это первоапрельская шутка. Естественно, 418 не используется нигде всерьез и просто существует как дань памяти программистам-юмористам, придумавшим это в 1998 году.

У Google получился такой симпатичный чайник

421 Misdirected Request

Появляется когда запрос клиента переправляется на сервер, который не может дать на него адекватный ответ. Например, если запрос был отправлен на ресурс, который вообще не настроен обрабатывать запросы извне.

Чтобы исправить проблему, можно попробовать переподключиться к ресурсу заново или попробовать другое соединение.

422 Unprocessable Entity

Код 422 говорит, что сервер вроде бы принял запрос, понял его, все хорошо, но из-за семантических ошибок корректно обработать не смог. Значит, где-то в запросе затаилась логическая ошибка, мешающая корректному взаимодействию клиента и сервера. Надо ее найти и исправить.

423 Locked

Обычно на этот код напарываются, когда запрашиваемый ресурс оказывается под защитой. Используемые клиентом методы блокируются на уровне сервера. Это делается, чтобы обезопасить данные, хранящиеся на защищенной странице. Без логина и пароля выудить информацию с такого сервера не получится.

424 Failed Dependency

424 сообщает о том, что для выполнения запроса со стороны клиента успешно должна завершиться еще одна или несколько параллельных операций. Если какая-то из них «провалится», то «помрет» все соединение сразу, и обработать запрос до конца не получится. Аналогичное происходит, если некорректно был обработан один из предыдущих запросов.

425 Too Early

Появляется в ответ на запрос, который может быть моментально запущен заново. Сервер не рискует и не берется за его обработку, чтобы не подставиться под так называемую «атаку повторного воспроизведения».

426 Upgrade Required

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

428 Precondition Required

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

429 Too Many Requests

Здесь все просто. Ошибка появляется, когда клиент отправляет на сервер слишком много запросов в короткий промежуток времени. Очень похоже на поведение взломщиков. По этой причине запрос моментально блокируется.

Из названия понятно, что ошибка с кодом 431 появляется из-за того, что в запросе клиента используются слишком длинные заголовки (неважно, один или несколько из них). Исправляется это с помощью сокращения заголовков и повторной отправки запроса. В теле ошибки обычно отображается краткая информация о том, как пользователь может решить эту проблему самостоятельно.

444 No Response

Этот код вам вряд ли удастся увидеть. Он отображается в лог-файлах, чтобы подтвердить, что сервер никак не отреагировал на запрос пользователя и прервал соединение.

449 Retry With

Код используется в расширениях компании Microsoft. Он сигнализирует о том, что запрос от клиента не может быть принят сервером. Причиной становятся неверно указанные параметры. Сама 449 ошибка говорит о необходимости скорректировать запрос и повторить его снова, подготовив к работе с сервером.

450 Blocked by Windows Parental Controls

450 код увидят дети, попавшие под действие системы «Родительский контроль» компании Microsoft. По сути, ошибка говорит о том, что с компьютера попытались зайти на заблокированный ресурс. Избежать этой ошибки можно изменением параметров родительского контроля.

451 Unavailable For Legal Reasons

Этот код сообщает клиенту, что он не может попасть на запрашиваемый ресурс из юридических соображений. Скорее всего, доступ был заблокирован из-за каких-нибудь государственных санкций, нового законодательства или цензуры со стороны властей. В общем, все вопросы к государству и провайдеру связи.

Источник

Ошибка 422: решение

Код состояния 422 (HTTP 422 Unprocessable Entity) обозначает ошибку со стороны пользователя, а не API. Сервер понимает запрос со стороны клиента и может работать с типом содержимого, который ему предоставили. Однако логическая ошибка делает выполнение невозможным.

Например, документ XML построен синтаксически грамотно, но со стороны семантики в инструкции содержится погрешность.

  • вы отправляете полезные данные, которые недействительны в формате JSON;
  • вы отправляете заголовки HTTP, такие как Content-Type или Accept, которые указывают значение, отличное от application / json;
  • запрос может быть валиден по отношению к JSON, но что-то не так с содержимым. Например, указание API обновить кластер до несуществующего варианта;
  • в теле или запросе содержится лишний символ или пробел (в первую очередь стоит проверить пробелы перед заголовком) или напротив, не хватает кавычек/проставлен неправильный тип. Самая актуальная проблема при работе с JSON, при которой может перестать работать весь код.

Проблема ошибка 422 через Ajax Post с использованием Laravel

В ajax этот код может выдаваться как ошибка по умолчанию, когда проверка не выполняется. Либо возвращаться Laravel при запросе, в котором допущена опечатка. Можно попробовать сделать запрос в консоли браузера: он должен выдать JSON с ошибками, возникшими во время проверки запроса. Есть вероятность, что код просто отправляет атрибуты формы не так, как вы запланировали. В любом случае, проблему решать программисту или вебмастеру.

Дополнительная информация

К сожалению, дать универсальный совет по исправлению ошибки 422 Unprocessable Entity непросто. Путь разрешения может сильно отличаться для каждой частной ситуации.

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

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

Дальше по теме…

Умные люди придумали коды, по которым можно определить, что произошло с HTTP-запросом. Успешен ли он, произошло ли перенаправление. Или же все закончилось ошибкой. Как раз об ошибках и будем говорить в этой статье. Вкратце расскажу, какие они бывают и с чем связаны. 

А еще тут будет парочка забавных (и не очень) пикч и анимаций на тему описанных ошибок. Хоть какое-то развлечение.

Ошибки со стороны клиента (4xx)

Для начала перечислим коды ошибок на стороне клиента. Вина за их появление ложится на плечи обоих участников соединения.

400 Bad Request

Такой ответ от браузера можно получить в том случае, если сервер не смог правильно отреагировать на запрос со стороны пользователя. Часто код 400 возникает при попытке клиента получить доступ к серверу без соблюдения правил оформления синтаксиса протокола передачи гипертекста (HTTP). Повторный запрос не стоит отправлять до тех пор, пока не будет исправлена ошибка (или несколько из них). 

401 Unauthorized

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

402 Payment Required

Эта ошибка сообщает клиенту о том, что для успешного выполнения запроса ему необходимо оплатить доступ к серверу. Изначально код 402 должен был стать неким стандартом для цифровой валюты и оплаты контента в сети. Но не срослось. До сих пор нет единого решения по поводу того, как должны выглядеть платежи в сети. Также нет и единого решения по поводу того, как стоит использовать 402. 

Все еще считается, что код существует с расчетом на будущее. Сейчас почти не используется и поддерживается не всеми браузерами.

403 Forbidden

Почти то же, что и 401. Сервер снова не разрешает к нему подключиться, хотя с запросом все в порядке. Просто нет доступа. Причем повторная авторизация с другими логином и паролем никак не помогут. Все вопросы к владельцам сервера (но не всегда). Инструкция по устранению ошибки. 

Анимация на тему 403 

Творчество на тему знаменитой киносаги

404 Not Found

Легендарная ошибка, ставшая популярным мемом. 404 оповещает клиента о том, что его запрос ведет в никуда. Код возникает, когда пользователь пытается попасть на страницу, которой не существует. Например, когда случайно ошибается при вводе ссылки и вводит ее с опечаткой. Или же пытается получить доступ к странице, которой на сайте уже нет. 

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

Ошибка 404

Еще вариант оформления ошибки 404

И таких вариаций тысячи. Каждый пытается добавить в оформление что-то свое.

405 Method Not Allowed

405 сообщает клиенту о том, что метод, используемый при запросе, не разрешен. В качестве примера можно привести попытку со стороны клиента ввести данные в форму с помощью GET, когда она работает только с POST. Ну и в таком же духе. 

406 Not Acceptable

Ошибка 406 сообщает о том, что страница передает контент, который не может быть распознан клиентом. Возможно, проблема в методе сжатия или в формате страницы. Иногда сюда же приплетают неправильные настройки кодировки.

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

407 Proxy Authentication Required

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

408 Request Timeout

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

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

Кадр из фильма Мистер Робот 

В Мистере Роботе частенько называли серии в честь ошибок HTTP (весь четвертый сезон в нумерации 4хх). В честь 408, например, назвали восьмую серию четвертого сезона

409 Conflict

Сообщение о конфликте возникает, когда запрос со стороны клиента не соответствует тому, чего ожидает сервер. В качестве примера приводят проблемы при проверки версий, когда пользователь пытается с помощью метода PUT загрузить на сервер новый файл, но там уже имеется более новая версия того же файла. Конфликта версий можно легко избежать, загрузив корректную версию.

410 Gone

Своего рода аналог 404. Разница лишь в том, что 410 намекает на перманентность отсутствия страницы. Так что этот код стоит использовать, когда на 100% уверен, что страница ушла в небытие (ну или с текущего адреса) навсегда. В любом другом случае есть универсальный 404. 

411 Length Required

411 оповещает пользователя о том, что сервер не желает принимать запрос со стороны клиента, потому что в нем не определен заголовок Content-Length. Да, это первый код в подборке, который смогут понять только люди, сведущие в настройке серверов. По-простому уложить сущность HTML-заголовков в этот материал не получится.

412 Precondition Failed

Еще один код, сообщающий о том, что сервер отклонил запрос пользователя и не разрешает доступ к выбранному ресурсу. Проблемы возникают при неправильной настройке работы методов, отличающихся от GET и HEAD. 

413 Payload Too Large/Request Entity Too Large

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

414 URI Too Long

Чем-то этот код похож на предыдущий. Здесь тоже идет речь о превышение лимита. Только теперь это касается не запроса со стороны клиента, а длины URI. То есть ссылки. Выходит, что адрес, используемый клиентом, больше, чем тот, что может обработать сервер. Как-то так. 

Такая ошибка иногда выскакивает при попытке взломать ресурс. Сайт так реагирует на слишком частые попытки воспользоваться потенциальными дырами в безопасности.

415 Unsupported Media Type

Ошибка 415 возникает, когда клиент пытается загрузить на сервер данные в неподходящем формате. В таком случае сервер просто отказывается принимать посылаемые файлы и разрывает соединение. Как и в случае с 413. 

416 Range Not Satisfiable

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

417 Expectation Failed

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

418 I’m a teapot

Код 418 можно увидеть, если сервер откажется варить кофе, потому что он чайник. Это первоапрельская шутка. Естественно, 418 не используется нигде всерьез и просто существует как дань памяти программистам-юмористам, придумавшим это в 1998 году.

Чайник на сайте Google

У Google получился такой симпатичный чайник

421 Misdirected Request

Появляется когда запрос клиента переправляется на сервер, который не может дать на него адекватный ответ. Например, если запрос был отправлен на ресурс, который вообще не настроен обрабатывать запросы извне. 

Чтобы исправить проблему, можно попробовать переподключиться к ресурсу заново или попробовать другое соединение.

422 Unprocessable Entity

Код 422 говорит, что сервер вроде бы принял запрос, понял его, все хорошо, но из-за семантических ошибок корректно обработать не смог. Значит, где-то в запросе затаилась логическая ошибка, мешающая корректному взаимодействию клиента и сервера. Надо ее найти и исправить.

423 Locked

Обычно на этот код напарываются, когда запрашиваемый ресурс оказывается под защитой. Используемые клиентом методы блокируются на уровне сервера. Это делается, чтобы обезопасить данные, хранящиеся на защищенной странице. Без логина и пароля выудить информацию с такого сервера не получится.

424 Failed Dependency

424 сообщает о том, что для выполнения запроса со стороны клиента успешно должна завершиться еще одна или несколько параллельных операций. Если какая-то из них «провалится», то «помрет» все соединение сразу, и обработать запрос до конца не получится. Аналогичное происходит, если некорректно был обработан один из предыдущих запросов.

425 Too Early

Появляется в ответ на запрос, который может быть моментально запущен заново. Сервер не рискует и не берется за его обработку, чтобы не подставиться под так называемую «атаку повторного воспроизведения».

426 Upgrade Required

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

428 Precondition Required

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

429 Too Many Requests

Здесь все просто. Ошибка появляется, когда клиент отправляет на сервер слишком много запросов в короткий промежуток времени. Очень похоже на поведение взломщиков. По этой причине запрос моментально блокируется. 

Ошибка 429

431 Request Header Fields Too Large

Из названия понятно, что ошибка с кодом 431 появляется из-за того, что в запросе клиента используются слишком длинные заголовки (неважно, один или несколько из них). Исправляется это с помощью сокращения заголовков и повторной отправки запроса. В теле ошибки обычно отображается краткая информация о том, как пользователь может решить эту проблему самостоятельно.

444 No Response

Этот код вам вряд ли удастся увидеть. Он отображается в лог-файлах, чтобы подтвердить, что сервер никак не отреагировал на запрос пользователя и прервал соединение. 

449 Retry With

Код используется в расширениях компании Microsoft. Он сигнализирует о том, что запрос от клиента не может быть принят сервером. Причиной становятся неверно указанные параметры. Сама 449 ошибка говорит о необходимости скорректировать запрос и повторить его снова, подготовив к работе с сервером.

450 Blocked by Windows Parental Controls

450 код увидят дети, попавшие под действие системы «Родительский контроль» компании Microsoft. По сути, ошибка говорит о том, что с компьютера попытались зайти на заблокированный ресурс. Избежать этой ошибки можно изменением параметров родительского контроля.

451 Unavailable For Legal Reasons

Этот код сообщает клиенту, что он не может попасть на запрашиваемый ресурс из юридических соображений. Скорее всего, доступ был заблокирован из-за каких-нибудь государственных санкций, нового законодательства или цензуры со стороны властей. В общем, все вопросы к государству и провайдеру связи.

Лого Роскомнадзора

Читайте также

Ошибка сервера 504

Ошибка сервера 403

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Подписаться

Список ошибок на стороне сервера (5xx)

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

500 Internal Server Error

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

Ошибка 500

Дело не в тебе, дело во мне (С)

 Синий экран смерти

501 Not Implemented

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

Иногда в теле ошибки еще пишут что-то в духе «Приходите попозже, возможно, в будущем нужная функция появится».

502 Bad Getaway

Можно встретить в том случае, если запрашиваемый сервер выступает в роли шлюза или прокси. Возникает из-за несогласования протоколов между вышестоящим серверов и его шлюзом. Рассказываем о том, как ее исправить, в этой статье. 

503 Service Unavailable

Появляется, когда сервер не может обработать запрос клиента по одной из двух технических причин:

  1. Слишком много пользователей в текущий момент пытаются отправить запросы, и у сервера не остается ресурсов, чтобы ответить кому-либо еще.
  2. На сервере ведутся технические работы, временно блокирующие его работу.

Обычно ошибка 503 носит временный характер, и для ее решения достаточно немного подождать. 

504 Gateway Timeout

Ошибка похожа на 408. Здесь же прокси-сервер пытается выйти на контакт с вышестоящим сервером, но не успевает это сделать до истечения тайм-аута. Отсюда и ошибка.

 Вариант оформления ошибки 504

505 HTTP Version Not Supported

Этот код похож на 426. Он тоже связан с неподходящей версией протокола HTTP. В этом случае нужно обеспечить и клиента, и сервер единой версией. Она, как правило, указывается в запросе со стороны пользователя. 

506 Variant Also Negotiates

Обычно с такой ошибкой сталкиваются только в том случае, если сервер изначально настроен неправильно. То есть это не сиюминутная проблема, а что-то серьезное на уровне базовой конфигурации. Тут придется потрудиться разработчикам. Выявить проблему и разрешить ее.

507 Insufficient Storage

Код 507 встречается в тех ситуациях, когда серверу не хватает пространства в хранилище для обработки запроса со стороны клиента. Проблема решается освобождением места или расширением доступного пространства. Тогда сервер сможет без проблем обработать запрос пользователя.

508 Loop Detected

Таким кодом сервер отзовется в случае, если заметит бесконечный цикл в запросе клиента. Можно расценивать его как провал запроса и выполняемой операции в целом.

509 Bandwidth Limit Exceeded

Возникает, если сервер начинает потреблять больше трафика, чем ему позволено. 

510 Not Extended

Появляется, если клиент посылает запрос на использование какого-либо расширения, отсутствующего на сервере. Чтобы исправить проблему, надо убрать декларирование неподдерживаемого расширения из запроса или добавить поддержку на сервер.

511 Network Authentication Required

511 код говорит о том, что перед тем как выйти в сеть, надо авторизоваться (ввести логин и пароль). Можно воспринимать это неким PPPoE подключением, когда от клиента требуются данные для авторизации.

Заключение

Закончили. Это все ошибки, которыми отзывается HTTP, если на стороне сервера или клиента что-то пошло не так. Наткнуться на большую их часть довольно тяжело. Особенно, если вы раньше только серфили в интернете, а не занимались разработкой сайтов. А тем, кто входит в эту стезю, полезно знать основные ошибки, так как, скорее всего, придется не раз их исправлять. 

Содержание

  • Что такое код ответа HTTP
  • Как проверить код состояния страницы
  • В браузере
  • В Яндекс.Вебмастере
  • В Google Search Console
  • 1* класс кодов (информационные сообщения)
  • 100 Continue
  • 101 Switching Protocols
  • 102 Processing
  • 103 Checkpoint
  • 105 Name Not Resolved
  • 2* класс кодов (успешно обработанные запросы)
  • 200 ОК
  • 201 Created
  • 202 Accepted
  • 203 Non‑Authoritative Information
  • 204 No Content
  • 205 Reset Content
  • 206 Partial Content
  • 207 Multi‑Status
  • 226 IM Used
  • 3* класс кодов (перенаправление на другой адрес)
  • 300 Multiple Choices
  • 301 Moved Permanently
  • 302 Found/Moved 
  • 303 See Other
  • 304 Not Modified
  • 305 Use Proxy
  • 306 Unused
  • 307 Temporary Redirect
  • 308 Resume Incomplete
  • 4* класс кодов (ошибки на стороне клиента)
  • 400 Bad Request
  • 401 Unauthorized
  • 402 Payment Required
  • 403 Forbidden
  • 404 Not Found
  • 405 Method Not Allowed
  • 406 Not Acceptable
  • 407 Proxy Authentication Required
  • 408 Request Timeout
  • 409 Conflict
  • 410 Gone
  • 411 Length Required
  • 412 Precondition Failed
  • 413 Request Entity Too Large
  • 414 Request‑URI Too Long
  • 415 Unsupported Media Type
  • 416 Requested Range Not Satisfiable
  • 417 Expectation Failed
  • 418 I’m a teapot
  • 422 Unprocessable Entity
  • 423 Locked
  • 424 Failed Dependency
  • 425 Unordered Collection
  • 426 Upgrade Required
  • 428 Precondition Required
  • 429 Too Many Requests
  • 431 Request Header Fields Too Large
  • 434 Requested Host Unavailable
  • 444 No Response
  • 449 Retry With
  • 450 Blocked by Windows Parental Controls
  • 451 Unavailable For Legal Reasons
  • 456 Unrecoverable Error
  • 499 Client Closed Request
  • 5* класс кодов (ошибки на стороне сервера)
  • 500 Internal Server Error
  • 501 Not Implemented
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout
  • 505 HTTP Version Not Supported
  • 506 Variant Also Negotiates
  • 507 Insufficient Storage
  • 508 Loop Detected
  • 509 Bandwidth Limit Exceeded
  • 510 Not Extended
  • 511 Network Authentication Required
  • Составили подробный классификатор кодов состояния HTTP. Добавляйте в закладки, чтобы был под рукой, когда понадобится.

    Что такое код ответа HTTP

    Когда посетитель переходит по ссылке на сайт или вбивает её в поисковую строку вручную, отправляется запрос на сервер. Сервер обрабатывает этот запрос и выдаёт ответ — трехзначный цифровой код HTTP от 100 до 510. По коду ответа можно понять реакцию сервера на запрос. 

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

    Как проверить код состояния страницы

    Проверить коды ответа сервера можно вручную с помощью браузера и в панелях веб‑мастеров: Яндекс.Вебмастер и Google Search Console.

    В браузере

    Для примера возьмём Google Chrome.

    1. Откройте панель разработчика в браузере клавишей F12, комбинацией клавиш Ctrl + Shift + I или в меню браузера → «Дополнительные инструменты» → «Инструменты разработчика». Подробнее об этом рассказывали в статье «Как открыть исходный код страницы». 

    2. Переключитесь на вкладку «Сеть» в Инструментах разработчика и обновите страницу: 

    Как посмотреть код ответа сервера в инструментах разработчика в браузере

    Как посмотреть код ответа сервера в инструментах разработчика в браузере

    В Яндекс.Вебмастере

    Откройте инструмент «Проверка ответа сервера» в Вебмастере. Введите URL в специальное поле и нажмите кнопку «Проверить»:

    Как посмотреть код состояния в Вебмастере

    Как посмотреть код состояния в Вебмастере

    Как добавить сайт в Яндекс.Вебмастер и другие сервисы Яндекса

    В Google Search Console

    Чтобы посмотреть код ответа сервера в GSC, перейдите в инструмент проверки URL — он находится в самом верху панели:

    Проверка URL в инструменте GSC

    Проверка URL в инструменте GSC

    Введите ссылку на страницу, которую хотите проверить, и нажмите Enter. В результатах проверки нажмите на «Изучить просканированную страницу» в блоке «URL есть в индексе Google».

    Изучить просканированную страницу в GSC

    Изучить просканированную страницу в GSC

    А затем в открывшемся окне перейдите на вкладку «Подробнее»:

    HTTP код страницы в GSC

    HTTP код страницы в GSC

    Теперь расскажем подробнее про все классы кодов состояния HTTP.

    1* класс кодов (информационные сообщения)

    Это системный класс кодов, который только информирует о процессе передачи запроса. Такие ответы не являются ошибкой, хотя и могут отображаться в браузере как Error Code.

    100 Continue

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

    101 Switching Protocols

    Сервер одобрил переключение типа протокола, которое запросил пользователь, и в настоящий момент выполняет действие.

    102 Processing

    Запрос принят — он находится в обработке, и на это понадобится чуть больше времени.

    103 Checkpoint

    Контрольная точка — используется в запросах для возобновления после прерывания запросов POST или PUT.

    POST отправляет данные на сервер, PUT создает новый ресурс или заменяет существующий данными, представленными в теле запроса. 

    Разница между ними в том, что PUT работает без изменений: повторное его применение даёт такой же результат, что и в первый раз, а вот повторный вызов одного и того же метода POST часто меняет данные. 

    Пример — оформленный несколько раз интернет‑заказ. Такое часто происходит как раз по причине неоднократного использования запроса PUT.

    105 Name Not Resolved

    Не удается преобразовать DNS‑адрес сервера — это  означает ошибку в службе DNS. Эта служба преобразует IP‑адреса в знакомые нам доменные имена.

    2* класс кодов (успешно обработанные запросы)

    Эти коды информируют об успешности принятия и обработки запроса. Также сервер может передать заголовки или тело сообщений. 

    200 ОК

    Все хорошо — HTTP‑запрос успешно обработан (не ошибка).

    201 Created

    Создано — транзакция успешна, сформирован новый ресурс или документ.

    202 Accepted

    Принято — запрос принят, но ещё не обработан.

    203 Non‑Authoritative Information

    Информация не авторитетна — запрос успешно обработан, но передаваемая информация была взята не из первичного источника (данные могут быть устаревшими).

    204 No Content

    Нет содержимого — запрос успешно обработан, однако в ответе только заголовки без контента сообщения. Не нужно обновлять содержимое документа, но можно применить к нему полученные метаданные.

    205 Reset Content

    Сбросить содержимое. Запрос успешно обработан — но нужно сбросить введенные данные. Страницу можно не обновлять.

    206 Partial Content

    Частичное содержимое. Сервер успешно обработал часть GET‑запроса, а другую часть вернул.

    GET — метод для чтения данных с сайта. Он говорит серверу, что клиент хочет прочитать какой‑то документ. 

    Представим интернет‑магазин и страницы каталога. Фильтры, которые выбирает пользователь, передаются благодаря методу GET. GET‑запрос работает с  получением данных, а POST‑запрос нужен для отправки данных.

    При работе с подобными ответами следует уделить внимание кэшированию.

    207 Multi‑Status

    Успешно выполнено несколько операций — сервер передал результаты выполнения нескольких независимых операций. Они появятся в виде XML‑документа с объектом multistatus. 

    226 IM Used

    Успешно обработан IM‑заголовок (специальный заголовок, который отправляется клиентом и используется для передачи состояния HTTP).

    3* класс кодов (перенаправление на другой адрес)

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

    300 Multiple Choices

    Множественный выбор — сервер выдает список нескольких возможных вариантов перенаправления (максимум — 5). Можно выбрать один из них.

    301 Moved Permanently

    Окончательно перемещено — страница перемещена на другой URL, который указан в поле Location.

    302 Found/Moved 

    Временно перемещено — страница временно перенесена на другой URL,  который указан в поле Location.

    303 See Other

    Ищите другую страницу — страница не найдена по данному URL, поэтому смотрите страницу по другому URL, используя метод GET.

    304 Not Modified

    Модификаций не было — с момента последнего визита клиента изменений не было.

    305 Use Proxy

    Используйте прокси — запрос к нужному ресурсу можно сделать только через прокси‑сервер, URL которого указан в поле Location заголовка.

    306 Unused

    Зарезервировано. Код в настоящий момент не используется.

    307 Temporary Redirect

    Временное перенаправление — запрашиваемый ресурс временно доступен по другому URL.

    Этот код имеет ту же семантику, что код ответа 302 Found, за исключением того, что агент пользователя не должен изменять используемый метод HTTP: если в первом запросе использовался POST, то во втором запросе также должен использоваться POST.

    308 Resume Incomplete

    Перемещено полностью (навсегда) — запрашиваемая страница была перенесена на новый URL, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается.

    4* класс кодов (ошибки на стороне клиента)

    Эти коды указывают на ошибки со стороны клиентов. 

    Скриншот страницы с ошибкой 404 с сайта modcloth.com

    Скриншот страницы с ошибкой 404 с сайта modcloth.com

    400 Bad Request

    Неверный запрос — запрос клиента не может быть обработан, так как есть синтаксическая ошибка (возможно, опечатка).

    401 Unauthorized

    Не пройдена авторизация — запрос ещё в обработке, но доступа нет, так как пользователь не авторизован.

    Для доступа к запрашиваемому ресурсу клиент должен представиться, послав запрос, включив при этом в заголовок сообщения поле Authorization.

    402 Payment Required

    Требуется оплата — зарезервировано для использования в будущем. Код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний.

    403 Forbidden

    Запрещено — запрос принят, но не будет обработан, так как у клиента недостаточно прав. Может возникнуть, когда пользователь хочет открыть системные файлы (robots, htaccess) или не прошёл авторизацию.

    404 Not Found

    Не найдено — запрашиваемая страница не обнаружена. Сервер принял запрос, но не нашёл ресурса по указанному URL (возможно, была ошибка в URL или страница была перемещена).

    405 Method Not Allowed

    Метод не разрешён — запрос был сделан методом, который не поддерживается данным ресурсом. Сервер должен предложить доступные методы решения в заголовке Allow.

    406 Not Acceptable

    Некорректный запрос — неподдерживаемый поисковиком формат запроса (поисковый робот не поддерживает кодировку или язык).

    407 Proxy Authentication Required

    Нужно пройти аутентификацию прокси — ответ аналогичен коду 401, только нужно аутентифицировать прокси‑сервер.

    408 Request Timeout

    Тайм‑аут запроса — запрос клиента занял слишком много времени. На каждом сайте существует свое время тайм‑аута — проверьте интернет‑соединение  и просто обновите страницу.

    409 Conflict

    Конфликт (что‑то пошло не так) — запрос не может быть выполнен из‑за конфликтного обращения к ресурсу (несовместимость двух запросов).

    410 Gone

    Недоступно — ресурс раньше был размещён по указанному URL, но сейчас удалён и  недоступен (серверу неизвестно месторасположение).

    411 Length Required

    Добавьте длины — сервер отклоняет отправляемый запрос, так как длина заголовка не определена, и он не находит значение Content‑Length. 

    Нужно исправить заголовки на сервере, и в следующий раз робот сможет проиндексировать страницу.

    412 Precondition Failed

    Предварительное условие не выполнено — стоит проверить правильность HTTP‑заголовков данного запроса.

    413 Request Entity Too Large

    Превышен размер запроса — перелимит максимального размера запроса, принимаемого сервером. Браузеры поддерживают запросы от 2 до 8 килобайт.

    414 Request‑URI Too Long

    Превышена длина запроса — сервер не может обработать запрос из‑за длинного URL. Такая ошибка может возникнуть, например, когда клиент пытается передать чересчур длинные параметры через метод GET, а не POST.

    415 Unsupported Media Type

    Формат не поддерживается —  сервер не может принять запрос, так как  данные подгружаются в некорректном формате, и сервер разрывает соединение.

    416 Requested Range Not Satisfiable

    Диапазон не поддерживается — ошибка возникает в случаях, когда в самом HTTP‑заголовке прописывается некорректный байтовый диапазон.

    Корректного диапазона в необходимом документе может просто не быть, или есть опечатка в синтаксисе.

    417 Expectation Failed

    Ожидания не оправдались — прокси некорректно идентифицировал содержимое поля «Expect: 100‑Continue».

    418 I’m a teapot

    Первоапрельская шутка разработчиков в 1998 году. В расшифровке звучит как «я не приготовлю вам кофе, потому что я чайник». Не используется в работе.

    422 Unprocessable Entity

    Объект не обработан — сервер принял запрос, но в нём  есть логическая ошибка. Стоит посмотреть в сторону семантики сайта.

    423 Locked

    Закрыто — ресурс заблокирован для выбранного HTTP‑метода. Можно перезагрузить роутер и компьютер. А также использовать только статистический IP.

    424 Failed Dependency

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

    Выполнение запроса напрямую зависит от успешности выполнения другой операции, и если она не будет успешно завершена, то вся обработка запроса будет прервана.

    425 Unordered Collection

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

    426 Upgrade Required

    Нужно обновление — в заголовке ответа нужно корректно сформировать поля Upgrade и Connection. 

    Этот ответ возникает, когда серверу требуется обновление до SSL‑протокола, но клиент не имеет его поддержки.

    428 Precondition Required

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

    429 Too Many Requests

    Слишком много запросов — отправлено слишком много запросов за короткое время. Это может указывать, например, на попытку DDoS‑атаки, для защиты от которой запросы блокируются.

    431 Request Header Fields Too Large

    Превышена длина заголовков — сервер может и не отвечать этим кодом, вместо этого он может просто сбросить соединение.

    Исправляется это с помощью сокращения заголовков и повторной отправки запроса.

    434 Requested Host Unavailable

    Адрес запрашиваемой страницы недоступен.

    444 No Response

    Нет ответа — код отображается в лог‑файлах, чтобы подтвердить, что сервер никак не отреагировал на запрос пользователя и прервал соединение. Возвращается только сервером nginx.

    Nginx — программное обеспечение с открытым исходным кодом. Его используют для создания веб‑серверов, а также  в качестве почтового или обратного прокси‑сервера. Nginx решает проблему падения производительности из‑за роста трафика. 

    449 Retry With

    Повторите попытку — ошибка говорит о необходимости скорректировать запрос и повторить его снова. Причиной становятся неверно указанные параметры (возможно, недостаточно данных).

    450 Blocked by Windows Parental Controls

    Заблокировано родительским контролем — говорит о том, что с компьютера попытались зайти на заблокированный ресурс. Избежать этой ошибки можно изменением параметров системы родительского контроля.

    451 Unavailable For Legal Reasons

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

    456 Unrecoverable Error

    Неустранимая ошибка — при обработке запроса возникла ошибка, которая вызывает некорректируемые сбои в таблицах баз данных.

    499 Client Closed Request

    Запрос закрыт клиентом — нестандартный код, используемый nginx в ситуациях, когда клиент закрыл соединение, пока nginx обрабатывал запрос.

    5* класс кодов (ошибки на стороне сервера)

    Эти коды указывают на ошибки со стороны серверов. 

    При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя. И его можно использовать в работе.

    Изображение страницы с ошибкой сайта REG.RU

    Изображение страницы с ошибкой сайта REG.RU

    500 Internal Server Error

    Внутренняя ошибка сервера — сервер столкнулся с неким условием, из‑за которого не может выполнить запрос. 

    Проверяйте, корректно ли указаны директивы в системных файлах (особенно htaccess) и нет ли ошибки прав доступа к файлам. Обратите внимание на ошибки внутри скриптов и их медленную работу.

    501 Not Implemented

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

    Сами вы эту ошибку не исправите. Устранить её может только сервер.

    502 Bad Gateway

    Ошибка шлюза — появляется, когда сервер, выступая в роли шлюза или прокси‑сервера, получил ответное сообщение от вышестоящего сервера о несоответствии протоколов.

    Актуально исключительно для прокси и шлюзовых конфигураций.

    503 Service Unavailable

    Временно не доступен — сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). 

    В поле Retry‑After заголовка сервер укажет время, через которое  можно повторить запрос.

    504 Gateway Timeout

    Тайм‑аут шлюза —  сервер, выступая в роли шлюза или прокси‑сервера, не получил ответа от вышестоящего сервера в нужное время.

    Исправить эту ошибку самостоятельно не получится. Здесь дело в прокси, часто — в веб‑сервере. 

    Первым делом просто обновите веб‑страницу. Если это не помогло, нужно почистить DNS‑кэш. Для этого  нажмите горячие клавиши Windows+R и введите команду cmd (Control+пробел). В открывшемся окне укажите команду ipconfig / flushdns и подтвердите её нажатием Enter.

    505 HTTP Version Not Supported

    Сервер не поддерживает версию протокола — отсутствует поддержка текущей версии HTTP‑протокола. Нужно обеспечить клиента и сервер одинаковой версией.

    506 Variant Also Negotiates

    Неуспешные переговоры — с такой ошибкой сталкиваются, если сервер изначально настроен неправильно. По причине ошибочной конфигурации выбранный вариант указывает сам на себя, из‑за чего процесс и прерывается.

    507 Insufficient Storage

    Не хватает места для хранения — серверу недостаточно места в хранилище. Нужно либо расчистить место, либо увеличить доступное пространство.

    508 Loop Detected

    Обнаружен цикл — ошибка означает провал запроса и выполняемой операции в целом.

    509 Bandwidth Limit Exceeded

    Превышена пропускная способность —  используется при чрезмерном потреблении трафика. Владельцу площадки следует обратиться к своему хостинг‑провайдеру. 

    510 Not Extended

    Не продлён — ошибка говорит, что на сервере отсутствует нужное для клиента расширение. Чтобы исправить проблему, надо убрать часть неподдерживаемого расширения из запроса или добавить поддержку на сервер.

    511 Network Authentication Required

    Требуется аутентификация — ошибка генерируется сервером‑посредником, к примеру, сервером интернет‑провайдера, если нужно ввести пароль для получения доступа к сети через платную точку доступа.

    Чтобы решить эту проблему,вы всегда должны убедиться,что при отправке данных задан правильный тип содержимого.В данном случае вам следует установить заголовок Content-Type на application/json при отправке любых данных в формате JSON в Redmine.Обратите внимание,что в принципе,вы можете отправлять в Redmine данные в формате XML и получать обратно JSON.

    Код статуса ответа HyperText Transfer Protocol (HTTP)422 Unprocessable Entity указывает на то,что сервер понимает тип содержимого объекта запроса,синтаксис объекта запроса правильный,но не смог обработать содержащиеся в нем инструкции.

    Код состояния 422 возникает,когда запрос хорошо сформирован,но из-за семантических ошибок не может быть обработан.Этот статус HTTP был введен в RFC 4918 и более конкретно ориентирован на расширения HTTP для Web Distributed Authoring and Versioning (WebDAV).

    Код состояния HTTP — это ответ сервера на запрос браузера. Когда вы посещаете веб-сайт, ваш браузер отправляет запрос на сервер сайта, а затем сервер отвечает на запрос браузера трехзначным кодом: кодом состояния HTTP.

    Что такое глитч в Minecraft ошибка 422? Глюк-это пиксельная сущность,которая появится в вашем мире,когда вы продолжите играть в Minecraft версии ошибки 422.Глюк нельзя убить,и убежать от него невозможно,так как он знает,где вы находитесь.

    Как проверить код ответа сервера и понять его значение. Подробный перечень частых ошибок HTTP с пояснениями.

    В статье:

    1. Как проверить код ответа сервера

    2. Значения кодов ответов сервера

    3. Информационные коды

    4. Коды успешной обработки запроса

    5. Коды редиректов

    6. Коды ошибок клиента

    7. Коды ошибок сервера

     При каждом обращении к серверу вы получаете от него код статуса ответа. Коды связаны с функциональностью страниц сайта и сигнализируют о состоянии страницы. Благодаря значению, которое несет код, сервер корректирует обработку документа после запроса пользователя. Самые популярные коды — 200, который показывает, что запрос выполнен успешно, и 404, показывающий ошибку, если ресурс не найден.

    На код ответа сервера обращают внимание поисковые боты и браузеры.

    Как проверить код ответа сервера

    Посмотреть код ответа на странице можно бесплатно за пару кликов. В браузере информация находится на панели разработчика: в Google Chrome для вызовите панель горячей клавишей F12, откройте вкладку Network и обновите страницу.

    Как посмотреть код сайта в браузере

    Результаты просмотра кода в браузере

    Для просмотра кода есть браузерные расширения:
    HTTP Headers для Google Chrome, HTTP Header для Opera.

    Инструмент в Яндекс.Вебмастере покажет код статуса HTTP.

    проверка кода ответа сервера

    Результаты проверки инструментом

    Инструмент
    проверки заголовков сервера от PR-CY определит HTTP статусы сайта и доменного имени.

    как проверить код ответа сервера

    Результаты проверки инструментом

    Значения кодов ответов сервера

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

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

    • 1— — информационный код, отвечающий за передачу данных.
      Такие коды временны и показывают, что запрос принят и обрабатывается.
    • 2— — код успешной обработки запроса.
      Сервис получил и обработал запрос.
    • 3— — код редиректа.
      Сервер сигнализирует, что для выполнения запроса нужно предпринять дополнительные действия, к примеру, перейти на другой адрес.
    • 4— — клиентская ошибка.
      Ошибка на стороне клиента. Возможно, пользователь что-то сделал неправильно, и поэтому запрос не может быть успешно обработан.
    • 5— — серверная ошибка.
      По какой-то внутренней причине сервер не может выполнить пользовательский запрос.

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

    Информационные коды

    Коды этой группы информируют о том, что сервер принял запрос и будет его обрабатывать.

    100 Continue

    Сервер принял запрос и удовлетворен начальными сведениями. Процесс обработки будет продолжен.

    101 Switching Protocols

    Сервер одобрил переключение типа протокола, которое запросил пользователь. Код используется, когда сервер предлагает перейти на новую версию HTTP. В поле Update будут перечислены доступные протоколы, пользователь может выбрать один из них.

    102 Processing

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

    Коды успешной обработки запроса

    Коды группы сигнализируют о том, что запрос принят и успешно обработан.

    200 ОК

    Это один из самых популярных ответов, он означает, что запрос принят и успешно обработан, страница открыта и доступна к просмотру. Все страницы, которые будут проиндексированы, должны отдавать код 200 ОК.

    201 Created

    Ответ означает, что сервер принял запрос, обработал и создал новый ресурс. Код можно увидеть, к примеру, если пользователь создал новую страницу. Если новый ресурс создать невозможно, или он перестанет существовать к тому времени, когда клиент получит сообщение, то сервер отдаст код 202 Accepted.

    202 Accepted

    Сервер принял запрос, но не завершил его обработку. Запрос можно отклонить, поскольку на его выполнение может потребоваться слишком много времени.

    203 Non-Authoritative Information

    Код ответа 203 означает, что операция прошла успешно, но от кода 200 он отличается указанием источника информации. Данные получены не из первоисточника, а с другого сервера или резервной копии. Возможно, информация устарела, о чем и предупреждает код ответа.

    204 No Content

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

    205 Reset Content

    Сервер сигнализирует, что запрос успешно обработан и клиенту нужно сбросить введенные данные. Обновление документа не требуется, сервер не передает тело сообщения.

    206 Partial Reset

    Этот код обычно используют инструменты кэширования. Сервер в ответе возвращает только часть контента страницы, которую и запрашивает пользователь.

    207 Multi-Status

    Код обозначает мультистатусность ответа: сервер обработал несколько операций,не зависящих друг от друга. Результаты отображаются в теле сообщения как XML-документ с объектом multistatus.

    226 IM Used

    Сервер успешно завершил операцию: принял заголовок A-IM и вернул содержимое с учетом указанных параметров.

    Коды редиректов

    Класс кодов показывает, что для успешного выполнения запроса клиенту нужно совершить переход, то есть редирект.

    300 Multiple Choices

    Робот не может проиндексировать страницу, поскольку не может сопоставить ресурс и URL. Частая причина — ресурс перемещен на другой адрес. Сервер предлагает клиенту выбор альтернатив для перехода. Для успешной индексации нужно либо правильно указать ресурс, либо поправить заголовки.

    301 Moved Permanently

    Если у проиндексированной страницы изменился адрес, то со старого URL на новый настраивают 301 редирект. Код ответа показывает, что запрашиваемый документ был навсегда перенесен на другой URL, куда пользователя перенаправляет ссылка. Робот проиндексирует страницу, на которую ведет редирект, и склеит исходный адрес и новый.

    302 Found

    Код означает не постоянное, а временное перемещение страницы на другой адрес, поэтому страницу удалять из индекса не нужно. В ответе указано новое расположение данных.

    Страница остается в индексе, ссылочный вес продолжает передаваться.

    303 See Other

    Сервер сигнализирует, что ресурс, который указан в запросе, расположен на другом адресе. Обычно он используется для перенаправления пользователя к выбранному ресурсу выводом данных POST-активированного скрипта.

    В ответе сервера будет указан адрес, по которому нужно искать результат, удовлетворяющий запрос.

    304 Not Modified

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

    305 Use Proxy

    Код ответа связан с безопасностью данных. Сервер выдает код 305, если доступ к ресурсу, который запрашивает клиент, возможен только с прокси. Прокси указан там же в ответе сервера.

    307 Temporary Redirect

    Код 307 похож на 302, но дает более конкретный ответ. Код означает, что ресурс, который требует клиент, на время переведен на другой адрес, а новый URL нужно прописать в Location.

    Коды ошибок клиента

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

    400 Bad Request

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

    401 Unauthorized

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

    403 Forbidden

    Запрос успешно получен и верно сформулирован, но у сервера нет доступа к запрашиваемой странице. Возможно, доступ ограничен специально для определенных IP-адресов с помощью файла .htaccess.

    Если пользователю www-data, под которым запущен сервер, закрыт доступ к чтению файла, поможет команда sudo chmod o=r /usr/share/nginx/html/index.html

    Еще одна причина — пользователь обратился к закрытому каталогу, в котором нет индексного файла. Разрешение на просмотр каталога включается в настройках сервера.

    404 Not Found

    Серверу не удалось найти ресурс, который запрашивает пользователь, документа по этому адресу не существует.

    Это частая ошибка, она может быть связана с тем, что пользователь ошибся в адресе страницы, у пользователя нет прав на чтение и исполнение файла, файл на сервере переместили иди удалили, корневой каталог указали с ошибкой или сервер не настроен для работы с символьными «мягкими» ссылками, которые использованы для обработки.

    проверить код ответа сервера

    Код ответа 404 Not Found

    Ссылки на удаленные разделы сайта будут возвращать код 404. На такие документы не нужно тратить краулинговый бюджет, поэтому в файле robots.txt запрещают роботу посещение и индексацию таких страниц.

    405 Method Not Allowed

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

    406 Not Acceptable

    Код ответа означает, что запрашиваемый файл существует, запрос сформулирован верно, но кодировка документа недоступна для расшифровки роботом.

    407 Proxy Authentication Required

    Этот код похож на 401 и 407, он используется, если вопрос корректен, но клиент может получить доступ к документу только с помощью авторизации через прокси. Клиент авторизуется, если прокси вернет поле с заголовком proxy-authenticate.

    408 Request Timeout

    Сервер возвращает этот код ответа, если в установленное время ожидания клиент не сделал ни один запрос. Код 408 не возвращается, если пользователь сам отменил запрос, или соединение оборвалось, а отправить ответ нет возможности.

    409 Conflict

    Код означает, что в системе конфликт: к примеру, пользователь загружает файл на сервер, где уже есть такой файл в новой версии.

    410 Gone

    Код ответа похож на 404 код, он означает, что документ, к которому направлен запрос, больше недоступен. Если сервер возвращает код 404, то робот еще вернется на страницу, чтобы проверить ее состояние, а в случае ответа 410 робот поймет, что страница удалена навсегда.

    411 Length Required

    Сервер не может принять и обработать запрос, если в заголовке content-length не указана длина контента.

    413 Request Entity Too Large

    Если в теле запроса слишком большой объем информации и сервер не может обработать такой большой запрос, то он возвращает код ошибки 413. Если это временная проблема, в поле Retry-After сервер укажет время, которое нужно подождать.

    414 Request-URL Too Long

    Аналогично с кодом 413, за исключением того, что 414 код отображается, если в запросе указан слишком длинный URL.

    422 Unprocessable Entity

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

    424 Failed Dependency

    Если выполнение этой операции зависит от исхода других связанных с ней операций, сервер вернет этот запрос.

    429 Too Many Requests

    Код 429 означает, что пользователь посылает слишком много запросов за короткий временной промежуток, и сервер не может обработать такое количество.

    431 Request Header Fields Too Large

    Если в запросе указаны слишком большие поля заголовков, сервер не сможет справиться с таким запросом и вернет код ошибки 431.

    451 Unavailable For Legal Reasons

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

    418 I’m a teapot

    Это забавный код, возвращающий ошибку «Я чайник», связан с гипертекстовым протоколом управления кофеваркой — Hyper Text Coffee Pot Control Protocol. Ошибка означает, что запрос некорректен, с помощью чайника нельзя приготовить кофе. Протокол и код этой ошибки были созданы в шутку в 1998 году к 1 апреля.

    Код 418 I’m a teapot

    Коды ошибок сервера

    Коды этой группы обозначают ошибки на стороне сервера.

    500 Internal Server Error

    Код обозначает, что сервер не может обработать запрос по причине внутренних ошибок. Обычно проблема в настройке сервера, обращении к некорректному файлу .htaccess или пакету PHP, который не установлен.

    501 Not Implemented

    Сервер возвращает этот код, когда не может обработать запрос: он не поддерживает возможности для обработки или не может распознать метод. К примеру, эта ошибка появится, если распространенные протоколы HEAD, POST, GET и другие по какой-то причине не поддерживаются сервером.

    502 Bad Gateway

    За обработку запроса отвечают бэкенд серверы, которые передают данные прокси-серверу или шлюзу. Если запрос был направлен к такому шлюзу, который не получил ответ от бэкенда, сервер вернет 502 код. Для исправления нужно проверить настройку прокси-сервера.

    503 Service Unavailable

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

    504 Gateway Timeout

    Код похож на 502, но ошибка 504 означает, что истек срок ожидания ответа от сервера. Необходимое количество времени истекло, а ответ от бэкенд-сервера не пришел.

    Причина может быть в сетевом соединении, недостатке ресурсов, версии протокола HTTP или настройке сервера, если выставлен слишком короткий таймаут.

    506 Variant Also Negotiates

    Код ответа 506 означает, что сервер настроен некорректно: ошибка в конфигурации зацикливает обращение сервера, и он указывает сам на себя.

    507 Insufficient Storage

    Если сервер загружен настолько, что для выполнения запроса не хватает памяти, он вернет ошибку 507. Это бывает, если на сервере нет места для данных в принимаемом запросе.

    510 Not Extended

    Код 510 возвращается в случае, если сервер не поддерживает расширение, которое указано в запросе. В этом же ответе сервер может указать, какие расширения доступны.

    511 Network Authentication Required

    Эта ошибка возвращается клиенту, если пользователь не авторизовался в сети. К примеру, если он не согласился на условия использования интернета, когда подключался к wi-fi, или не ввел пароль.


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

    nginx config as follows:

    server {
                listen 80;
                listen [::]:80;
    
                add_header 'Access-Control-Allow-Origin' $http_origin;
                add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, DELETE, PUT, PATCH';
                add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range';
                add_header 'Access-Control-Max-Age' 1728000;
    
                server_name erp.dev.thinkerx.com;
                access_log  /home/thinkerx/nginx/access.log;
                error_log /home/thinkerx/nginx/error.log;
                location ~ /.well-known {
                        allow all;
                }
    
                # The rest of your server block
                root /usr/share/nginx/html/men2017-back-dev/public;
                index index.html index.htm index.php;
    
                location /api/ {
                        try_files $uri $uri/ /index.php$is_args$args;
                }
    
                location ~ .php$ {
                                try_files $uri /index.php =404;
                                fastcgi_pass 127.0.0.1:9000;
                                fastcgi_index index.php;
                                fastcgi_buffers 16 16k;
                                fastcgi_buffer_size 32k;
                                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                                include fastcgi_params;
                        }
        }
    

    js code as follows:

    $.ajax({
        type: 'post',
        dataType: 'json',
        contentType: 'application/json; charset=UTF-8',
        url: "http://erp.dev.thinkerx.com/api/external/material/catalogs",
        data: JSON.stringify({
            domain_id: 2222,
            code:'X01',
            name:'123063'
        }),
        success: function (response) {
            console.log(response);      
        },
        error: function (xhr, status, error) {
            console.log(xhr, status, error);    
        },
    });
    

    then, send request in browser, chrome console shows two request. The first request is preflight, method is OPTION. The second is real request and has response, whose status code is 201.
    preflight request

    {"data":{"id":"16b7d6a0-9eb6-42ca-9ddb-fc61f5e082c0","domain_id":2222,"name":"1230464","code":"X01","parent_id":null,"created_at":1504698369,"updated_at":1504698369}}
    

    As above, the thing is expected, but i update ajax data.

    $.ajax({
        type: 'post',
        dataType: 'json',
        contentType: 'application/json; charset=UTF-8',
        url: "http://erp.dev.thinkerx.com/api/external/material/catalogs",
        data: JSON.stringify({
            domain_id: 2222,
            code:'X01',
            // name:'123063'
        }),
        success: function (response) {
            console.log(response);      
        },
        error: function (xhr, status, error) {
            console.log(xhr, status, error);    
        },
    });
    

    i send the request again.Accidentally, the error occurred.
    also two requests, the second status code is 422

    {“message”:”Validation Failed”,”errors”:[[“Key name must be
    present”]],”status_code”:422}

    XMLHttpRequest cannot load
    http://erp.dev.thinkerx.com/api/external/material/catalogs. No
    ‘Access-Control-Allow-Origin’ header is present on the requested
    resource. Origin ‘http://localhost’ is therefore not allowed access.
    The response had HTTP status code 422.

    I has some questions as follows:

    1. Why report same origin policy error?
    2. I see the response in console, why ajax xhr.responseJSON is undefined? How to fetch the response?

    Добавить комментарий