Пользователь уже существует код ошибки

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

Я определил API, чтобы клиенты могли создавать или изменять объекты с помощью PUT:

PUT /objects/{id} HTTP/1.1
...

{json representation of the object}

{id} — это идентификатор объекта, поэтому он является частью запроса-URI.

теперь я также рассматриваю возможность разрешить клиентам создавать объект с помощью Сообщение:

POST /objects/ HTTP/1.1
...

{json representation of the object, including ID}

поскольку POST подразумевается как операция «добавить», я не уверен, что делать, если объект уже есть. Должен ли я рассматривать запрос как запрос на изменение или должен вернуть некоторый код ошибки (который)?

15 ответов

Мне кажется 409 Conflict является наиболее подходящим, однако, редко встречается в дикой природе:

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

конфликты, скорее всего, возникнут в ответ на запрос PUT. Например, если используется управление версиями и объект, который помещается, включает изменения в ресурс, которые противоречат тем, которые были сделаны более ранним (сторонним) запросом, сервер может использовать ответ 409, чтобы указать, что он не может выполнить запрос. В этом случае объект ответа, скорее всего, будет содержать список различий между двумя версиями в формате, определенном типом содержимого ответа.

лично я иду с расширением WebDAV 422 Unprocessable Entity.

Rest Patterns описывает его как

на 422 Unprocessable Entity код состояния означает, что сервер понимает тип содержимого сущности запроса (следовательно,415 Unsupported Media Type код состояния неуместен), и синтаксис сущности запроса правильный (таким образом,400 Bad Request код состояния неуместен), но не удалось обработать содержащиеся инструкции.

по данным RFC 7231, a 303 См. Другие можно использовать если результат обработки поста будет эквивалентен
представление существующего ресурса.

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

чтобы немного расширить ответ Wrikken, я думаю, вы могли бы использовать либо 409 Conflict или 403 Forbidden в зависимости от ситуации-короче говоря, используйте ошибку 403, когда пользователь не может ничего сделать для разрешения конфликта и завершения запроса (например, они не могут отправить DELETE запрос на явное удаление ресурса), или используйте 409, если что-то может быть сделанный.

10.4.4 403 запрещено

сервер понял запрос, но отказывается выполнять его.
Разрешение не поможет, и запрос не должен повторяться. Если
метод запроса не был HEAD, и сервер хочет сделать общедоступным
почему запрос не был выполнен, в нем должна быть описана причина
за отказ в сущности. Если сервер не желает делать
эта информация доступна клиенту, код состояния 404 (не
Найдено) можно использовать вместо этого.

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

по состоянию на PUT и POST… POST должен использоваться для создания нового экземпляра ресурса, когда пользователь не имеет средств или не должен создавать идентификатор для ресурс. PUT используется, когда идентификатор ресурса известен.

9.6 поставить

…

принципиальная разница между запросами POST и PUT заключается в
отражается в различном значении запроса-URI. URI в a
POST-запрос определяет ресурс, который будет обрабатывать вложенный
сущность. Этот ресурс может быть процессом приема данных, шлюзом для
какой-то другой протокол или отдельный объект, который принимает аннотации. В
напротив, URI в запросе PUT идентифицирует сущность, заключенную в
запрос — агент пользователя знает, что URI предназначен и
сервер не должен пытаться применить запрос к какому-либо другому ресурсу.
Если сервер желает, чтобы запрос был применен к другому URI,

он должен отправить 301 (перемещенный постоянно) ответ; агент пользователя может
затем принять собственное решение относительно того, следует ли перенаправлять
запрос.

» 302 найдено » звучит логично для меня. И RFC 2616 говорит, что на него можно ответить для других запросов, кроме GET и HEAD (и это, безусловно, включает POST)

но он по-прежнему держит посетителя на этот URL, чтобы получить этот «найденный» ресурс, RFC. Чтобы заставить его перейти непосредственно к реальному «найденному» URL-адресу, нужно использовать «303 See Other», что имеет смысл, но заставляет другой вызов получить следующий URL-адрес. С хорошей стороны, это GET кэшируемый.

думаю, что Я бы использовал «303 см. Другие». Я не знаю, Могу ли я ответить» вещью», найденной в теле, но я хотел бы сделать это, чтобы сохранить одну поездку туда и обратно на сервер.

обновление: после перечитывания RFC, я все еще думаю, что не существует «4xx+303 найдено» код должен быть правильным. Однако «409 конфликт» является лучшим существующим кодом ответа (как указано @ Wrikken), возможно, включая Заголовок местоположения, указывающий на существующий ресурс.

Я не думаю, что вы должны сделать это.

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

используйте его для добавления элемента без идентификатора. Это лучшая практика.

Если вы хотите захватить уникальное ограничение (не id), вы можете ответить 409, как вы можете сделать в запросах PUT. Но не ИДЕНТИФИКАТОР.

зачем 202 принято? Это запрос OK (200s), не было никаких ошибок клиента (400s), как таковых.

С 10 Определений Кода Состояния:

«202 принято. Запрос был принят для обработки, но обработка не была завершена.»

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

Я опираюсь на бросок 202 и возвращаю аналогичный контент в what a GET /{resource}/{id} вернули бы.

6

автор: Phillip Harrington

Я думаю, что для отдыха вам просто нужно принять решение о поведении для этой конкретной системы, и в этом случае, я думаю, что «правильный» ответ будет одним из пары ответов, приведенных здесь. Если вы хотите, чтобы запрос остановился и вел себя так, как будто клиент совершил ошибку, которую он должен исправить, прежде чем продолжить, используйте 409. Если конфликт действительно не так важен и вы хотите сохранить запрос, ответьте, перенаправив клиента на найденную сущность. Я думаю, что правильный REST APIs должно быть перенаправление (или, по крайней мере, предоставление заголовка местоположения) в конечную точку GET для этого ресурса после публикации, Так что это поведение даст согласованный опыт.

изменить:
Также стоит отметить, что вы должны рассмотреть PUT, так как вы предоставляете идентификатор. Тогда поведение просто: «мне все равно, что там сейчас, положите эту вещь туда.- Это значит, что если там ничего нет, оно будет создано; если там что-то есть, оно будет заменено. Я думаю, что сообщение больше подходит, когда сервер управляет этим ID. Разделение двух концепций в основном говорит вам, как с этим бороться (т. е. PUT является идемпотентным, поэтому он всегда должен работать до тех пор, пока полезная нагрузка проверяет, POST всегда создает, поэтому, если есть столкновение идентификаторов, то 409 будет описывать этот конфликт).

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

патч решит проблему, позволяя вам обновлять уже существующие элементы. См.: RFC 5789: PATCH

Я бы пошел с 422 Unprocessable Entity, который используется, когда запрос недействителен, но проблема не в синтаксисе или аутентификации.

в качестве аргумента против других ответов использовать любые не —4xx код ошибки означает, что это не ошибка клиента, и это очевидно. Чтобы использовать4xx код ошибки для представления ошибки клиента просто не имеет смысла.

кажется,409 Conflict является наиболее распространенным ответом здесь, но, согласно спецификации, это означает, что ресурс уже существует, и новые данные, которые вы применяете к нему, несовместимы с его текущим состоянием. Если вы посылаете POST запрос, например, имя пользователя, которое уже занято, на самом деле не конфликтует с целевым ресурсом, поскольку целевой ресурс еще не был опубликован. Это ошибка специально для управления версиями, когда существует конфликт между версией сохраненного ресурса и версией запрошенного ресурса. Это очень полезно для этой цели, для пример, когда клиент кэширует старую версию ресурса и отправляет запрос на основе этой неправильной версии, которая больше не будет условно допустимой. «В этом случае представление ответа, вероятно, будет содержать информацию, полезную для объединения различий на основе истории изменений.»Запрос на создание другого пользователя с этим именем пользователя просто необработан, не имея ничего общего с контролем версий.

для записи, 422 статус кода GitHub используется при попытке создать репозиторий с уже используемым именем.

насчет 208 — http://httpstatusdogs.com/208-already-reported ? Это вариант?

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

2

автор: Fernando Ferreira

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

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

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

https://tools.ietf.org/html/rfc7231#section-6.4.1

скорее это 400 Bad Request

6.5.1. 400 Плохой Запрос

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

поскольку запрос содержит повторяющееся значение(value что уже существует), то это может быть воспринято как ошибка клиента. Нужно изменить запрос перед следующей попыткой.
Рассматривая эти факты, мы можем заключить, что HTTP STATUS 400 плохой запрос.

Это все контекст, а также кто несет ответственность за наличие дубликатов (сервер или клиент или оба)

Если сервер просто точка дубликат, посмотрите на 4xx:

  • 400 Bad Request — когда сервер не будет обрабатывать запрос, потому что это очевидная ошибка клиента
  • 409 конфликт — если сервер не будет обрабатывать запрос, но причина этого не является ошибкой клиента

для подразумевается обработка дубликатов, посмотрите на 2XX:

  • 200 OK
  • 201 создан

если сервер ожидалось что-то вернуть, посмотрите на 3XX:

  • 302 нашел
  • 303 См. Другие

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

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

Источник

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

Я определил API, чтобы клиенты могли создавать или изменять объекты с помощью PUT:

PUT /objects/{id} HTTP/1.1
...

{json representation of the object}

{id} — это идентификатор объекта, поэтому он является частью запроса-URI.

теперь я также рассматриваю возможность разрешить клиентам создавать объект с помощью Сообщение:

POST /objects/ HTTP/1.1
...

{json representation of the object, including ID}

поскольку POST подразумевается как операция «добавить», я не уверен, что делать, если объект уже есть. Должен ли я рассматривать запрос как запрос на изменение или должен вернуть некоторый код ошибки (который)?

15 ответов

Мне кажется 409 Conflict является наиболее подходящим, однако, редко встречается в дикой природе:

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

конфликты, скорее всего, возникнут в ответ на запрос PUT. Например, если используется управление версиями и объект, который помещается, включает изменения в ресурс, которые противоречат тем, которые были сделаны более ранним (сторонним) запросом, сервер может использовать ответ 409, чтобы указать, что он не может выполнить запрос. В этом случае объект ответа, скорее всего, будет содержать список различий между двумя версиями в формате, определенном типом содержимого ответа.

лично я иду с расширением WebDAV 422 Unprocessable Entity.

Rest Patterns описывает его как

на 422 Unprocessable Entity код состояния означает, что сервер понимает тип содержимого сущности запроса (следовательно,415 Unsupported Media Type код состояния неуместен), и синтаксис сущности запроса правильный (таким образом,400 Bad Request код состояния неуместен), но не удалось обработать содержащиеся инструкции.

по данным RFC 7231, a 303 См. Другие можно использовать если результат обработки поста будет эквивалентен
представление существующего ресурса.

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

чтобы немного расширить ответ Wrikken, я думаю, вы могли бы использовать либо 409 Conflict или 403 Forbidden в зависимости от ситуации-короче говоря, используйте ошибку 403, когда пользователь не может ничего сделать для разрешения конфликта и завершения запроса (например, они не могут отправить DELETE запрос на явное удаление ресурса), или используйте 409, если что-то может быть сделанный.

10.4.4 403 запрещено

сервер понял запрос, но отказывается выполнять его.
Разрешение не поможет, и запрос не должен повторяться. Если
метод запроса не был HEAD, и сервер хочет сделать общедоступным
почему запрос не был выполнен, в нем должна быть описана причина
за отказ в сущности. Если сервер не желает делать
эта информация доступна клиенту, код состояния 404 (не
Найдено) можно использовать вместо этого.

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

по состоянию на PUT и POST… POST должен использоваться для создания нового экземпляра ресурса, когда пользователь не имеет средств или не должен создавать идентификатор для ресурс. PUT используется, когда идентификатор ресурса известен.

9.6 поставить

…

принципиальная разница между запросами POST и PUT заключается в
отражается в различном значении запроса-URI. URI в a
POST-запрос определяет ресурс, который будет обрабатывать вложенный
сущность. Этот ресурс может быть процессом приема данных, шлюзом для
какой-то другой протокол или отдельный объект, который принимает аннотации. В
напротив, URI в запросе PUT идентифицирует сущность, заключенную в
запрос — агент пользователя знает, что URI предназначен и
сервер не должен пытаться применить запрос к какому-либо другому ресурсу.
Если сервер желает, чтобы запрос был применен к другому URI,

он должен отправить 301 (перемещенный постоянно) ответ; агент пользователя может
затем принять собственное решение относительно того, следует ли перенаправлять
запрос.

» 302 найдено » звучит логично для меня. И RFC 2616 говорит, что на него можно ответить для других запросов, кроме GET и HEAD (и это, безусловно, включает POST)

но он по-прежнему держит посетителя на этот URL, чтобы получить этот «найденный» ресурс, RFC. Чтобы заставить его перейти непосредственно к реальному «найденному» URL-адресу, нужно использовать «303 See Other», что имеет смысл, но заставляет другой вызов получить следующий URL-адрес. С хорошей стороны, это GET кэшируемый.

думаю, что Я бы использовал «303 см. Другие». Я не знаю, Могу ли я ответить» вещью», найденной в теле, но я хотел бы сделать это, чтобы сохранить одну поездку туда и обратно на сервер.

обновление: после перечитывания RFC, я все еще думаю, что не существует «4xx+303 найдено» код должен быть правильным. Однако «409 конфликт» является лучшим существующим кодом ответа (как указано @ Wrikken), возможно, включая Заголовок местоположения, указывающий на существующий ресурс.

Я не думаю, что вы должны сделать это.

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

используйте его для добавления элемента без идентификатора. Это лучшая практика.

Если вы хотите захватить уникальное ограничение (не id), вы можете ответить 409, как вы можете сделать в запросах PUT. Но не ИДЕНТИФИКАТОР.

зачем 202 принято? Это запрос OK (200s), не было никаких ошибок клиента (400s), как таковых.

С 10 Определений Кода Состояния:

«202 принято. Запрос был принят для обработки, но обработка не была завершена.»

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

Я опираюсь на бросок 202 и возвращаю аналогичный контент в what a GET /{resource}/{id} вернули бы.

6

автор: Phillip Harrington

Я думаю, что для отдыха вам просто нужно принять решение о поведении для этой конкретной системы, и в этом случае, я думаю, что «правильный» ответ будет одним из пары ответов, приведенных здесь. Если вы хотите, чтобы запрос остановился и вел себя так, как будто клиент совершил ошибку, которую он должен исправить, прежде чем продолжить, используйте 409. Если конфликт действительно не так важен и вы хотите сохранить запрос, ответьте, перенаправив клиента на найденную сущность. Я думаю, что правильный REST APIs должно быть перенаправление (или, по крайней мере, предоставление заголовка местоположения) в конечную точку GET для этого ресурса после публикации, Так что это поведение даст согласованный опыт.

изменить:
Также стоит отметить, что вы должны рассмотреть PUT, так как вы предоставляете идентификатор. Тогда поведение просто: «мне все равно, что там сейчас, положите эту вещь туда.- Это значит, что если там ничего нет, оно будет создано; если там что-то есть, оно будет заменено. Я думаю, что сообщение больше подходит, когда сервер управляет этим ID. Разделение двух концепций в основном говорит вам, как с этим бороться (т. е. PUT является идемпотентным, поэтому он всегда должен работать до тех пор, пока полезная нагрузка проверяет, POST всегда создает, поэтому, если есть столкновение идентификаторов, то 409 будет описывать этот конфликт).

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

патч решит проблему, позволяя вам обновлять уже существующие элементы. См.: RFC 5789: PATCH

Я бы пошел с 422 Unprocessable Entity, который используется, когда запрос недействителен, но проблема не в синтаксисе или аутентификации.

в качестве аргумента против других ответов использовать любые не —4xx код ошибки означает, что это не ошибка клиента, и это очевидно. Чтобы использовать4xx код ошибки для представления ошибки клиента просто не имеет смысла.

кажется,409 Conflict является наиболее распространенным ответом здесь, но, согласно спецификации, это означает, что ресурс уже существует, и новые данные, которые вы применяете к нему, несовместимы с его текущим состоянием. Если вы посылаете POST запрос, например, имя пользователя, которое уже занято, на самом деле не конфликтует с целевым ресурсом, поскольку целевой ресурс еще не был опубликован. Это ошибка специально для управления версиями, когда существует конфликт между версией сохраненного ресурса и версией запрошенного ресурса. Это очень полезно для этой цели, для пример, когда клиент кэширует старую версию ресурса и отправляет запрос на основе этой неправильной версии, которая больше не будет условно допустимой. «В этом случае представление ответа, вероятно, будет содержать информацию, полезную для объединения различий на основе истории изменений.»Запрос на создание другого пользователя с этим именем пользователя просто необработан, не имея ничего общего с контролем версий.

для записи, 422 статус кода GitHub используется при попытке создать репозиторий с уже используемым именем.

насчет 208 — http://httpstatusdogs.com/208-already-reported ? Это вариант?

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

2

автор: Fernando Ferreira

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

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

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

https://tools.ietf.org/html/rfc7231#section-6.4.1

скорее это 400 Bad Request

6.5.1. 400 Плохой Запрос

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

поскольку запрос содержит повторяющееся значение(value что уже существует), то это может быть воспринято как ошибка клиента. Нужно изменить запрос перед следующей попыткой.
Рассматривая эти факты, мы можем заключить, что HTTP STATUS 400 плохой запрос.

Это все контекст, а также кто несет ответственность за наличие дубликатов (сервер или клиент или оба)

Если сервер просто точка дубликат, посмотрите на 4xx:

  • 400 Bad Request — когда сервер не будет обрабатывать запрос, потому что это очевидная ошибка клиента
  • 409 конфликт — если сервер не будет обрабатывать запрос, но причина этого не является ошибкой клиента

для подразумевается обработка дубликатов, посмотрите на 2XX:

  • 200 OK
  • 201 создан

если сервер ожидалось что-то вернуть, посмотрите на 3XX:

  • 302 нашел
  • 303 См. Другие

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

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

Я думал 403. Из http://www.restapitutorial.com/httpstatuscodes.html:

Сервер понял запрос, но отказывается его выполнить. Авторизация не поможет, и запрос НЕ ДОЛЖЕН повторяться. Если метод запроса не был HEAD и сервер желает обнародовать, почему запрос не был выполнен, он ДОЛЖЕН описать причину отказа в объекте. Если сервер не желает предоставлять эту информацию клиенту, вместо этого можно использовать код состояния 404 (Не найден).

Изменить: конечная точка — POST /users.

4 ответа

Лучший ответ

Обычный код ошибки HTTP для подобных ситуаций — 409 Conflict :

Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса. Этот код разрешен только в ситуациях, когда ожидается, что пользователь сможет разрешить конфликт и повторно отправить запрос. Тело ответа ДОЛЖНО содержать достаточно информации, чтобы пользователь мог распознать источник конфликта. В идеале объект ответа должен включать достаточно информации для пользователя или пользовательского агента, чтобы исправить проблему; однако это может быть невозможно и не требуется.

Это должно быть выполнено в ответ на POST или PUT, обычно как часть какого-либо RESTful API. Он должен включать полезное сообщение об ошибке в дополнение к статусу, и ошибка должна быть соответствующим образом закодирована (например, с помощью XML или JSON).

Неизвестные ошибки HTTP менее полезны во интерфейсных веб-службах. Если вы разрабатываете веб-сайт, ориентированный на пользователя, предпочтительнее просто предоставить HTML-страницу, объясняющую проблему, со стандартным 200 OK.


3

Kevin
1 Авг 2015 в 02:42

На мой взгляд, 403 — нормальный ответ. Также возможны варианты 409 и 412.


0

Vic F
1 Авг 2015 в 02:43

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

Почему бы просто не отправить:

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


0

Lance
1 Авг 2015 в 02:31

Как посмотреть ошибки автосинхронизации

При настройке автосинхронизации для приложений на базе SAML могут возникать следующие ошибки:

  • Ошибки этапа настройки

  • Ошибки выполнения автосинхронизации

  • Ошибки на уровне ресурсов

Ниже описано, как их устранить.

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

Ошибки этапа настройки

Ошибка кода авторизации

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

Сообщение об ошибке Решение
Не удалось сгенерировать токен авторизации. Повторите попытку и сохраните изменения.

Ошибка устаревшей страницы

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

Сообщение об ошибке Решение
Данные на странице устарели. Конфигурация синхронизации настроена. Чтобы переопределить существующие настройки, обновите страницу.
Данные на странице устарели. Конфигурация синхронизации отсутствует. Чтобы переопределить существующие настройки, обновите страницу.
Данные на странице устарели. Активировать ненастроенную конфигурацию синхронизации нельзя. Чтобы переопределить существующие настройки, обновите страницу.
Данные на странице устарели. Удалить ненастроенную конфигурацию синхронизации нельзя. Чтобы переопределить существующие настройки, обновите страницу.

Временная ошибка страницы

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

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

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

Эту ошибку можно устранить вручную: нажмите Управлять доступом клиента API в разделе Безопасность.

Если вы планируете позже восстановить конфигурацию, ничего не делайте. 
Не удалось обновить настройки синхронизации. Обновите страницу. 
Ошибка аутентификации. Учетные данные для аутентификации (например, токен владельца) указаны неверно. Задайте правильные учетные данные.
Введенный вами URL конечной точки системы кросс-доменного управления учетными данными (SCIM) недействителен. URL конечной точки недействителен. Введите правильный URL.
Не удалось включить синхронизацию. Переведите ползунок Автосинхронизация в положение Активный. 
Не удалось удалить настройки синхронизации.
  1. Нажмите Автосинхронизация, чтобы открыть настройки.
  2. В разделе Удаление конфигурации нажмите Удалить. 
Не удалось загрузить атрибуты целевого поставщика услуг.
  1. Нажмите Автосинхронизация, чтобы открыть настройки.
  2. В разделе Сопоставление атрибутов нажмите Изменить.
  3. Внесите нужные изменения.
Не удалось загрузить набор атрибутов целевого ресурса. Проверьте URL конечной точки, указанный при настройке автосинхронизации, и повторите сопоставление атрибутов облачного каталога с атрибутами целевого приложения.

Ошибки выполнения автосинхронизации

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

Ошибки внутренних сервисов Google

Код ошибки Описание и решение
17003
17006
17008

Описание 

Не удалось пройти аутентификацию во внутренних сервисах Google.

Причина

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

910835873219-es01p47a1ks618hgp59q26cnc6sv33r3.apps.googleusercontent.com

Решение 

Убедитесь, что у данного идентификатора есть разрешения на доступ к следующим областям:

https://www.googleapis.com/auth/admin.directory.user.readonly,
https://www.googleapis.com/auth/admin.directory.userschema.readonly,
https://www.googleapis.com/auth/admin.directory.group.member.readonly

В разделе Безопасность консоли администратора нажмите Управлять доступом клиента API и перейдите в раздел Расширенные настройки. Проверьте доступ идентификатора к указанным областям и при необходимости добавьте их.
17007

Описание

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

Не удалось делегировать права на уровне домена сервису автосинхронизации. Без этих прав сервис автосинхронизации не сможет читать каталог Google.

Причины

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

Решения

В разделе Безопасность консоли администратора нажмите Управлять доступом клиента API и перейдите в раздел Расширенные настройки. Добавьте идентификатор клиента и области действия:

Идентификатор клиента:
910835873219-es01p47a1ks618hgp59q26cnc6sv33r3.apps.googleusercontent.com

Области действия:

https://www.googleapis.com/auth/admin.directory.user.readonly,
https://www.googleapis.com/auth/admin.directory.userschema.readonly,
https://www.googleapis.com/auth/admin.directory.group.member.readonly

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

Причина 2: непредвиденные системные ошибки.

Решение

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

Ошибки токена авторизации

Код ошибки Описание и причина Решение
17010

Недостаточно учетных данных для вызова конечной точки SCIM.

Причина: токен авторизации аннулирован.

 Повторите попытку авторизации. Для этого нажмите Автосинхронизация и в настройках выберите Авторизовать повторно.
17013

Ошибка получения токена доступа у поставщика услуг.

Причина: токен авторизации аннулирован.

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

Ошибки доступа к токену

Код ошибки Описание и причина Решение
17002
17011

Не удалось создать токен доступа.

Причина: сейчас некоторые внутренние сервисы Google недоступны.

 Проблема должна устраниться автоматически.
17009 Не удалось создать токен доступа из токена обновления. Повторите попытку авторизации. Для этого нажмите Автосинхронизация и в настройках выберите Авторизовать повторно.

Общие ошибки

Код ошибки Описание и причина Решение
1200x

Внутренняя ошибка

 Проблема должна устраниться автоматически.
25001 Сервер или сервис Google временно недоступны. Настройте автосинхронизацию ещё раз.
25002

Сервер или сервис Google временно недоступны. 

Причина: у клиента не установлено приложение.

 Установите приложение и настройте автосинхронизацию ещё раз.
25005 Сервер или сервис Google временно недоступны. Проблема должна устраниться автоматически.
25016 Сервер или сервис Google временно недоступны. Настройте автосинхронизацию ещё раз.
50001 Внутренняя ошибка Проблема должна устраниться автоматически.
50003 Внутренняя ошибка Проблема должна устраниться автоматически.
50005 Удаленная группа присутствует в фильтрах групп. Удалите данную группу из области синхронизации.
50006 Внутренняя ошибка Проблема должна устраниться автоматически. 

Ошибки на уровне ресурсов

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

Эти ошибки влияют только на конкретные ресурсы, указанные в файле. 

Код ошибки Описание ошибки Решение
45003

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

Возможные причины:

  1. Превышено максимальное количество лицензий. В приложении на базе SCIM можно создать 5 пользователей, а вы включили автосинхронизацию для 6 пользователей.
  2. Слишком длинное значение. Например, идентификатор сообщения содержит слишком много символов, поэтому приложение его не принимает.
  3. Необходимо иметь хотя бы одно право доступа, одним из которых должно быть право на использование идентификатора профиля.
  4. Имя пользователя уже существует. Оно должно быть уникальным в масштабах организации.
  5. Ресурс (пользователь) не найден на стороне поставщика.
  6. Недопустимое значение идентификатора пользователя SCIM.
 После устранения ошибки сохраните изменения и повторите попытку.
45004

Произошла ошибка при передаче данных между поставщиком услуг и Google в качестве поставщика идентификационной информации. Текст ошибки: «Внутренняя ошибка – превышена квота».

Возможные причины:

  • Сбой, повлиявший на работу поставщика услуг.
  • Сервер поставщика услуг не работает.
 Обратитесь к поставщику услуг.
45005 Конечная точка системы кросс-доменного управления учетными данными (SCIM) недоступна. Проверьте данные в консоли администратора. После устранения ошибки сохраните изменения и повторите попытку.
45006

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

Возможные причины:

  1. слишком длинное значение;
  2. недостаточно лицензий;
  3. недействительная лицензия;
  4. значение для данного разрешения не существует.
 После устранения ошибки сохраните изменения и повторите попытку.
45016

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

 После устранения ошибки сохраните изменения и повторите попытку.

Эта информация оказалась полезной?

Как можно улучшить эту статью?

День добрый. Написал апи для мобильного приложения. Написано оно на php(один из популярных фреймворков). Работает всё отлично, обрабатываю ошибку. Но возник вопрос. Какие коды http ошибок возвращать? Приведу пример, чтобы была ясна суть вопроса.

Например. Мобильное приложение посылает запрос на апи для авторизации юзера. Сам запрос дошел до апи, но пароль не подходит. По сути, мы должны вернуть 200 OK, так как запрос дошел, но ведь данные с пользовательской информацией не вернулись мобильному приложению. И что возвращать? 500, 404 и т.д. И множество подобных примеров можно привести. Разъясните пожалуйста.

P.S. Знаю, что фейсбук всегда шлет 200 OK, но мне кажется это неправильно.

К чему вопрос. Не понимаю как обрабатывать коды ошибок на самом мобильном приложении. Например:

$http.post('http://api/v1/users/index/', {'login': user.login, 'password': user.password}).
			success(function(data) {
				$localStorage.userAuthData = data.response;
				console.log(data.response);
				if (data.response !== 'Password is not valid.') {
					if (data.response.approved == 0) 
					{
						$location.path('/success-reg');
					};
					if (data.response.approved == undefined)
					{
						$location.path('/success-auth');
					};
				} else {
					$ionicLoading.show({
						template: 'Bad password'
					});
					$timeout(function() {
						$ionicLoading.hide();
					}, 800);
				};
			}).
			error(function(err) {
				$ionicLoading.show({
					template: 'Bad request'
				});
				$timeout(function() {
					$ionicLoading.hide();
				}, 800);
			});

Здесь сработает Bad request. Потому что не вернутся 200 OK. Но тогда я не смогу обрабатывать ошибки типа пароль неправильный или юзера не существует.

Умные люди придумали коды, по которым можно определить, что произошло с 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, если на стороне сервера или клиента что-то пошло не так. Наткнуться на большую их часть довольно тяжело. Особенно, если вы раньше только серфили в интернете, а не занимались разработкой сайтов. А тем, кто входит в эту стезю, полезно знать основные ошибки, так как, скорее всего, придется не раз их исправлять. 

I receive user already exists error code when I try to create account programmaticaly in windows 7, although user does not exists. What may be the cause of this problem ?

int wmain(int argc, wchar_t *argv[])
{
USER_INFO_1 ui;
ui.usri1_name =L"test-PC";
ui.usri1_password = L"12";
ui.usri1_priv = USER_PRIV_USER;
ui.usri1_home_dir = NULL;
ui.usri1_comment = NULL;
ui.usri1_flags = UF_SCRIPT;
ui.usri1_script_path = NULL;

addUser(NULL, ui);

while(true){}
return 0;

}

int addUser(LPWSTR servername, USER_INFO_1 ui) {
DWORD dwLevel = 1;
DWORD dwError = 0;

// Call the NetUserAdd function, specifying level 1.
NET_API_STATUS nStatus = NetUserAdd(servername, dwLevel, (LPBYTE)&ui, &dwError);

// If the call succeeds, inform the user.
// Nerr_Success error code is 0 independant from nerr_base
if (nStatus == NERR_Success) {
    fwprintf(stderr, L"ADD: User %s has been successfully added on %sn", "1", "2");
    return 1;
}
//Nerr_base should be given since userexists is calculated by adding nerr_base to error code
else if((NERR_BASE + nStatus) == NERR_UserExists) 
    fprintf(stderr, "ADD: Account already exists: %dn", nStatus);
else if(NERR_BASE + nStatus == ERROR_ACCESS_DENIED)
    fprintf(stderr, "ADD: Access Denied: %dn", nStatus);
else if(NERR_BASE + nStatus == NERR_PasswordTooShort)
    fprintf(stderr, "ADD: Password is too short: %dn", nStatus);
else if(NERR_BASE + nStatus == NERR_PasswordTooLong)
    fprintf(stderr, "ADD: Password is too long: %dn", nStatus);
else
    fprintf(stderr, "ADD: A system error has occurred2: %dn", nStatus);

return 0;

}

I receive user already exists error code when I try to create account programmaticaly in windows 7, although user does not exists. What may be the cause of this problem ?

int wmain(int argc, wchar_t *argv[])
{
USER_INFO_1 ui;
ui.usri1_name =L"test-PC";
ui.usri1_password = L"12";
ui.usri1_priv = USER_PRIV_USER;
ui.usri1_home_dir = NULL;
ui.usri1_comment = NULL;
ui.usri1_flags = UF_SCRIPT;
ui.usri1_script_path = NULL;

addUser(NULL, ui);

while(true){}
return 0;

}

int addUser(LPWSTR servername, USER_INFO_1 ui) {
DWORD dwLevel = 1;
DWORD dwError = 0;

// Call the NetUserAdd function, specifying level 1.
NET_API_STATUS nStatus = NetUserAdd(servername, dwLevel, (LPBYTE)&ui, &dwError);

// If the call succeeds, inform the user.
// Nerr_Success error code is 0 independant from nerr_base
if (nStatus == NERR_Success) {
    fwprintf(stderr, L"ADD: User %s has been successfully added on %sn", "1", "2");
    return 1;
}
//Nerr_base should be given since userexists is calculated by adding nerr_base to error code
else if((NERR_BASE + nStatus) == NERR_UserExists) 
    fprintf(stderr, "ADD: Account already exists: %dn", nStatus);
else if(NERR_BASE + nStatus == ERROR_ACCESS_DENIED)
    fprintf(stderr, "ADD: Access Denied: %dn", nStatus);
else if(NERR_BASE + nStatus == NERR_PasswordTooShort)
    fprintf(stderr, "ADD: Password is too short: %dn", nStatus);
else if(NERR_BASE + nStatus == NERR_PasswordTooLong)
    fprintf(stderr, "ADD: Password is too long: %dn", nStatus);
else
    fprintf(stderr, "ADD: A system error has occurred2: %dn", nStatus);

return 0;

}

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

Я определил API, чтобы клиенты могли создавать или изменять объекты с помощью PUT:

PUT /objects/{id} HTTP/1.1

...


{json representation of the object}

{id} — это идентификатор объекта, поэтому он является частью запроса-URI.

теперь я также рассматриваю возможность разрешить клиентам создавать объект с помощью Сообщение:

POST /objects/ HTTP/1.1

...


{json representation of the object, including ID}

поскольку POST означает операцию «добавить», я не уверен, что делать, если объект уже существует. Должен ли я рассматривать запрос как запрос на изменение или я должен вернуть некоторый код ошибки (который)?


348  


15  

15 ответов:

Мне кажется 409 Conflict является наиболее подходящим, однако, редко встречается в дикой природе:

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

конфликты, скорее всего, возникнут в ответ на запрос PUT. Например, если используется управление версиями и помещаемый объект включает изменения в ресурс, которые конфликтуют с теми, которые были сделаны более ранним (сторонним) запросом, сервер может использовать ответ 409, чтобы указать, что он не может выполнить запрос. В этом случае объект ответа, скорее всего, будет содержать список различий между двумя версиями в формате, определенном типом содержимого ответа.

лично я иду с расширением WebDAV 422 Unprocessable Entity.

REST Patterns описывает его как

The 422 Unprocessable Entity код состояния означает, что сервер понимает тип содержимого объекта запроса (следовательно, a 415 Unsupported Media Type код состояния неуместен), и синтаксис объекта запроса является правильным (таким образом, a 400 Bad Request код состояния неуместен), но не смог обработать содержащиеся инструкции.

по данным RFC 7231, a 303 См. Другие можно использовать если результат обработки сообщения будет эквивалентен a
представление существующего ресурса.

поздно к игре может быть, но я наткнулся на эту проблему семантики при попытке сделать REST API.

чтобы немного расширить ответ Wrikken, я думаю, вы могли бы использовать либо 409 Conflict или 403 Forbidden в зависимости от ситуации — короче говоря, используйте ошибку 403, когда пользователь не может ничего сделать для разрешения конфликта и завершения запроса (например, они не могут отправить DELETE запрос на явное удаление ресурса), или использовать 409, если что-то может быть сделанный.

10.4.4 403 запрещено

сервер понял запрос, но отказывается выполнять его.
Авторизация не поможет, и запрос не должен повторяться. Если
метод запроса не был HEAD и сервер хочет сделать общедоступным
почему запрос не был выполнен, он должен описать причину
за отказ в юридическом лице. Если сервер не желает делать
эта информация доступна клиенту, код состояния 404 (не
Найдено) можно использовать вместо этого.

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

по состоянию на PUT и POST… POST должен использоваться для создания нового экземпляра ресурса, когда пользователь не имеет средств или не должен создавать идентификатор для ресурс. PUT используется, когда идентификатор ресурса известен.

9.6 PUT

…

принципиальная разница между запросами POST и PUT
находит свое отражение в различном значении URI в запросе. URI в a
Запрос POST идентифицирует ресурс, который будет обрабатывать прилагается
сущность. Этот ресурс может быть процессом приема данных, шлюзом для
какой-то другой протокол или отдельный объект, который принимает аннотации. В
напротив, URI в запросе put идентифицирует объект, заключенный с
запрос — агент пользователя знает, что URI предназначен и
сервер не должен пытаться применить запрос к какому-либо другому ресурсу.
Если сервер желает, чтобы запрос был применен к другому URI,

он должен отправить 301 (постоянно перемещенный) ответ; агент пользователя может
затем принять свое собственное решение относительно того, следует ли перенаправить
запрос.

«302 найдено» звучит логично для меня. А то RFC 2616 говорит, что на него можно ответить на другие запросы, чем GET и HEAD (и это, безусловно, включает в себя POST)

но он все еще держит посетителя, идущего на этот URL, чтобы получить этот «найденный» ресурс, RFC. Чтобы заставить его перейти непосредственно к реальному «найденному» URL, нужно использовать «303 See Other», что имеет смысл, но заставляет другой вызов получить его следующий URL. С хорошей стороны, это получить это кэшируемый.

думаю, что Я бы использовал «303 см. Другие». Я не знаю, Могу ли я ответить с помощью «вещи», найденной в теле, но я хотел бы сделать это, чтобы сохранить одну поездку туда и обратно на сервер.

обновление: после перечитывания RFC, я все еще думаю, что отсутствует «4xx+303 найдено» код должен быть правильным. Тем не менее, «409 конфликт» является лучшим существующим кодом ответа (как указано @ Wrikken), возможно, включая a Заголовок местоположения, указывающий на существующий ресурс.

Я не думаю, что вы должны сделать это.

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

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

Если вы хотите захватить уникальное ограничение(не идентификатор), вы можете ответить 409, как вы можете сделать в запросах PUT. Но не ИДЕНТИФИКАТОР.

почему бы и нет 202 принято? Это ОК запрос (200s), не было никаких ошибок клиента (400s), по сути.

С 10 Определений Кода Состояния:

«202 принято. Запрос был принят для обработки, но обработка не была завершена.»

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

Я опираюсь на бросок 202, и возвращаю аналогичный контент, чтобы получить /{resource}/{id} вернули бы.

Я думаю, что для отдыха вам просто нужно принять решение о поведении для этой конкретной системы, и в этом случае я думаю, что «правильный» ответ будет одним из нескольких ответов, приведенных здесь. Если вы хотите, чтобы запрос остановился и вел себя так, как если бы клиент допустил ошибку, которую он должен исправить перед продолжением, то используйте 409. Если конфликт действительно не так важен и вы хотите сохранить запрос, то ответьте, перенаправив клиента на объект, который был найден. Я думаю, что правильный отдых API должно быть перенаправление (или, по крайней мере, предоставление заголовка location) в конечную точку GET для этого ресурса после публикации в любом случае, поэтому это поведение даст согласованный опыт.

изменить:
Также стоит отметить, что вы должны рассмотреть PUT, так как вы предоставляете идентификатор. Тогда поведение просто: «мне все равно, что там сейчас, положите эту вещь туда.- То есть, если там ничего нет, оно будет создано; если там что-то есть, оно будет заменено. Я думаю, что пост больше если сервер управляет этим идентификатором. Разделение двух концепций в основном говорит вам, как с этим бороться (т. е. PUT является идемпотентным, поэтому он всегда должен работать до тех пор, пока полезная нагрузка проверяется, POST всегда создает, поэтому, если есть столкновение идентификаторов, то 409 будет описывать этот конфликт).

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

патч решит проблему, позволяя вам обновлять уже существующие элементы. Смотрите:RFC 5789: ПАТЧ

Я бы пошел с 422 Unprocessable Entity, который используется, когда запрос является недопустимым, но проблема не в синтаксисе или аутентификации.

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

кажется,409 Conflict является наиболее распространенным ответом здесь, но, согласно спецификации, это означает, что ресурс уже существует, и новые данные, которые вы применяете к нему, несовместимы с его текущим состоянием. Если вы отправляете POST запрос, например, с уже принятым именем пользователя, на самом деле не конфликтует с целевым ресурсом, поскольку целевой ресурс еще не был отправлен. Это ошибка специально для контроля версий, когда существует конфликт между версией сохраненного ресурса и версией запрошенного ресурса. Это очень полезно для этой цели, ибо пример, когда клиент кэширует старую версию ресурса и отправляет запрос на основе этой неправильной версии, которая больше не будет условно допустимой. «В этом случае представление ответа, вероятно, будет содержать информацию, полезную для объединения различий на основе истории пересмотра.»Запрос на создание другого пользователя с этим именем пользователя просто необработан, не имея ничего общего с контролем версий.

для записи, 422 также код состояния GitHub при попытке создать хранилище по имя уже используется.

насчет 208 — http://httpstatusdogs.com/208-already-reported ? Это вариант?

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

наткнулся на этот вопрос при проверке правильного кода для дубликата записи.

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

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

https://tools.ietf.org/html/rfc7231#section-6.4.1

скорее это 400 Bad Request

6.5.1. 400 Плохой Запрос

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

так как запрос содержит повторяющееся значение(value это уже существует), это может быть воспринято как ошибка клиента. Нужно изменить запрос перед следующей попыткой.
Рассматривая эти факты, мы можем заключить, что HTTP STATUS 400 Bad Request.

Это все контекст, а также кто несет ответственность за наличие дубликатов (сервер или клиент или оба)

Если сервер просто точка дубликат, посмотрите на 4xx:

  • 400 плохой запрос — когда сервер не будет обрабатывать запрос, потому что это очевидная ошибка клиента
  • 409 конфликт — если сервер не будет обрабатывать запрос, но причина этого не является ошибкой клиента

для подразумевается обработка дубликатов, посмотрите на 2XX:

  • 200 ОК
  • 201 создан

если сервер ожидал что-то вернуть, посмотрите на 3XX:

  • 302 нашел
  • 303 См. Другие

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

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

Коды ошибок

Коды ошибок
Материал из ISPWiki

В данном документе приводится описание кодов ошибок, возвращаемых панелью управления ISPmanager. При возникновении ошибки возвращается XML-документ, содержащий узел error. Например:

Код ошибки указывается в атрибуте code.

Содержание

  • 1 Internal error (код 1)
  • 2 Element already exists (код 2)
  • 3 Element not exists (код 3)
  • 4 Invalid value (код 4)
  • 5 Limit exceed (код 5)
  • 6 Access denied (код 6)
  • 7 Licence problem (код 7)
  • 8 Message error (код 8)
  • 9 Direct error (код 9)
  • 10 Addon error (код 10)
  • 11 Not enought money (код 11)

Internal error (код 1)

Ошибки с кодом 1 являются внутренними ошибками ISPmanager.

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

Например:

Failed to allocate memory

Element already exists (код 2)

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

Например:




Если в форме, в которой произошла такая ошибка, есть поле с именем «name». Например, в форме ISPmanager для создания БД — это имя базы. То, пользователь увидит ошибку: «Имя базы уже существует». В случае, если такого поля нет, пользователь увидит: «name уже существует». Аналогично manager поступает с ошибками с кодами: 3, 4, 5 и 6 (в ошибках 4 и 5 роль атрибута obj выполняет атрибут val).


Element not exists (код 3)




 Ошибки с кодом 3 указывают, что объект, к которому вы обращаетесь, не существует.


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




Invalid value (код 4)




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


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




Limit exceed (код 5)




 Ошибки с кодом 5 указывают, что превышено какое-то ограничение.


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


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




Access denied (код 6)



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

В этом случае может быть использован атрибут obj, в котором указывается к какому именно объекту нет доступа.


Licence problem (код 7)



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


Message error (код  8) 




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


Например:




Иванов Иван




в форме имеем:


Пользователь __param__ не зарегистрирован в системе




пользователь увидит сообщение: «Пользователь Иванов Иван не зарегистрирован в системе».


Direct error (код 9)



Ошибка 9 Обрабатывается аналогично ошибке с кодом 1.


Addon error (код 10)




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


Manager никогда не должен возвращать такую ошибку.




Not enought money (код 11)



Недостаточно средств для операции. Используется в BILLmanager










Источник






After having read this and several other, years-long, discussions on status code usage, the main conclusion I came to is that the specifications have to be read carefully, focusing on the terms being used, their definition, relationship, and the surrounding context.


What often happens instead, as can be seen from different answers, is that parts of the specifications are ripped of their context and interpreted in isolation, based on feelings and assumptions.


This is going to be a pretty long answer, the short summary of which is that HTTP 409 is the most appropriate status code to report the failure of an «add new resource» operation, in case a resource with the same identifier already exists. What follows is the explanation why, based solely on what’s stated in the authoritative source — RFC 7231.


So why is 409 Conflict the most appropriate status code in a situation described in the OP’s question?


RFC 7231 describes 409 Conflict status code as follows:




The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource.




The key components here are the target resource and its state.


Target resource


The resource is defined by the RFC 7231 as follows:




The target of an HTTP request is called a «resource». HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resources. Each resource is identified by a Uniform Resource Identifier (URI), as described in Section 2.7 of [RFC7230].




So, when using a HTTP interface, we always operate on the resources identified by URIs, by applying HTTP methods to them.


When our intention is to add a new resource, based on the OP’s examples, we can:


    

  • use PUT with the resource /objects/{id};
    • 

  • use POST with the resource /objects.
    • 



/objects/{id} is out of interest, because there can be no conflict when using a PUT method:




The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload.




If the resource with the same identifier already exists, it will be replaced by PUT.


So we’ll focus on the /objects resource and POST.


RFC 7231 says about the POST:




The POST method requests that the target resource process the representation enclosed in the request according to the resource’s own specific semantics.  For example, POST is used for the following functions (among others): … 3) Creating a new resource that has yet to be identified by the origin server; and 4) Appending data to a resource’s existing representation(s).




Contrary to how the OP understands POST method:




Since POST is meant as «append» operation…




Appending data to a resource’s existing representation is just one of the possible POST «functions». Moreover, what the OP actually does in the provided examples, is not directly appending data to the /objects representation, but creating a new independent resource /objects/{id}, which then becomes part of the /objects representation. But that’s not important.


What’s important is the notion of the resource representation, and it brings us to…


Resource state


RFC 7231 explains:




Considering that a resource could be anything, and that the uniform interface provided by HTTP is similar to a window through which one can observe and act upon such a thing only through the communication of messages to some independent actor on the other side, an abstraction is needed to represent («take the place of») the current or desired state of that thing in our communications. That abstraction is called a representation [REST].






For the purposes of HTTP, a «representation» is information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol, and that consists of a set of representation metadata and a potentially unbounded stream of representation data.




That’s not all, the specification continues to describe representation parts — metadata and data, but we can summarize that a resource representation, that consists of metadata (headers) and data (payload), reflects the state of the resource.


Now we have both parts needed to understand the usage of the 409 Conflict status code.


409 Conflict


Let’s reiterate:




The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource.




So how does it fit?


    

  1. We POST to /objects => our target resource is /objects.
    2. 

  2. OP does not describe the /objects resource, but the example looks like a common scenario where /objects is a resource collection, containing all individual «object» resources. That is, the state of the /objects resource includes the knowledge about all existing /object/{id} resources.
    3. 

  3. When the /objects resource processes a POST request it has to a) create a new /object/{id} resource from the data passed in the request payload; b) modify its own state by adding the data about the newly created resource.
    4. 

  4. When a resource to be created has a duplicate identifier, that is a resource with the same /object/{id} URI already exists, the /objects resource will fail to process the POST request, because its state already includes the duplicate /object/{id} URI in it.
    5. 



This is exactly the conflict with the current state of the target resource, mentioned in the 409 Conflict status code description.






Источник












A client sends the following to POST /account/register


{
  "username": "user123",
  "password": "pa55w0rd"
}



The server attempts to create the new account but finds that the username is already taken.


What should the most appropriate HTTP status code response be?


I’m thinking 409 Conflict however that means the client is then aware that the username exists, which might be a security issue? Or is it simply a case of visibility based on the type of site so depends on the situation?







        asked Oct 27, 2014 at 11:58
    




Greg's user avatar








3










I’d suggest returning error 409 Conflict:




The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request.







        answered Nov 16, 2018 at 16:08
    




Luke Taylor's user avatar






Luke TaylorLuke Taylor


8,4718 gold badges53 silver badges90 bronze badges
        












If your are concerned about privacy, regardless if the account was created or not make sure to respond the same way, and probably 204 or 202 are the most appropriated status code in this case.

To not confuse the user on the frontend you can display a generic message saying something like «You will receive a confirmation email on the next minutes if you don’t have an account, if you don’t receive the email try forget password».

Depending on how far you want to take things, you might want to create the account on a background process rather than in the main/request thread, otherwise attackers could analyze the response time of your endpoint and infer if the account was created or not based on the response time, this since the process of actually creating the account might take more time than just checking if it exists and returning.


Responding the same way in both scenarios is the only way to ensure an attacker can’t figure out who is already registered in your system.







        answered Jan 28, 2019 at 10:48
    




Jhuliano Moreno's user avatar











        answered Oct 27, 2014 at 12:08
    




just some guy's user avatar






just some guyjust some guy


5241 gold badge4 silver badges18 bronze badges
        














Источник








Я думал 403.  Из http://www.restapitutorial.com/httpstatuscodes.html:




Сервер понял запрос, но отказывается его выполнить.  Авторизация не поможет, и запрос НЕ ДОЛЖЕН повторяться.  Если метод запроса не был HEAD и сервер желает обнародовать, почему запрос не был выполнен, он ДОЛЖЕН описать причину отказа в объекте.  Если сервер не желает предоставлять эту информацию клиенту, вместо этого можно использовать код состояния 404 (Не найден).




Изменить: конечная точка — POST /users.




4 ответа


Лучший ответ




Обычный код ошибки HTTP для подобных ситуаций —  409 Conflict :




Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса.  Этот код разрешен только в ситуациях, когда ожидается, что пользователь сможет разрешить конфликт и повторно отправить запрос.  Тело ответа ДОЛЖНО содержать достаточно информации, чтобы пользователь мог распознать источник конфликта.  В идеале объект ответа должен включать достаточно информации для пользователя или пользовательского агента, чтобы исправить проблему;  однако это может быть невозможно и не требуется.




Это должно быть выполнено в ответ на POST или PUT, обычно как часть какого-либо RESTful API.  Он должен включать полезное сообщение об ошибке в дополнение к статусу, и ошибка должна быть соответствующим образом закодирована (например, с помощью XML или JSON).


Неизвестные ошибки HTTP менее полезны во интерфейсных веб-службах.  Если вы разрабатываете веб-сайт, ориентированный на пользователя, предпочтительнее просто предоставить HTML-страницу, объясняющую проблему, со стандартным 200 OK.






            3

            
          


Kevin

            1 Авг 2015 в 02:42
          








На мой взгляд, 403 — нормальный ответ.  Также возможны варианты 409 и 412.






            0

            
          


Vic F

            1 Авг 2015 в 02:43
          








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


Почему бы просто не отправить:


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






            0

            
          


Lance

            1 Авг 2015 в 02:31
          










Источник







  



                       
  





	









    
    
    
    



    

                
Понравилась статья? Поделить с друзьями:

        
        

























    








			

  • Получение сообщила об ошибке 0x80042108
    • 

  • Получение сертификата пфдо ошибка 500
    • 

  • Получение паспорта накопителя ошибка накопителя victoria
    • 

  • Получение капчи ошибка проверьте интернет соединение
    • 

  • Получение информации от есиа неизвестная ошибка

    •