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:

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:

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:

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:

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:

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:

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!

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

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

Источник

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?