-->

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

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

Я определил 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










Источник












I was thinking 403. From http://www.restapitutorial.com/httpstatuscodes.html:




The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.




Edit: Endpoint — POST /users.










Kevin's user avatar






Kevin


28.8k9 gold badges62 silver badges81 bronze badges
        









        asked Aug 1, 2015 at 2:25
    




Adam Zerner's user avatar






Adam ZernerAdam Zerner


17.7k15 gold badges89 silver badges153 bronze badges
        








4












The normal HTTP error code for situations like this is 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. The response body SHOULD include enough

  information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.




This should be issued in response to a POST or PUT, typically as part of some sort of RESTful API.  It should include a useful error message in addition to the status, and the error should be appropriately encoded (e.g. with XML or JSON).


Obscure HTTP errors are less useful in front-end web services.  If you are developing a user-facing website, it’s preferable to simply deliver an HTML page explaining the problem with a standard 200 OK.







        answered Aug 1, 2015 at 2:42
    




Kevin's user avatar








0








If you are creating a REST API to create accounts, I would expect the request to be something like:


POST /accounts HTTP/1.1 

{userid: "someone@example.com", password: "passw0rd!"}



In this case, I guess an appropriate response code would be 409 Conflict with an error description in the body


HTTP/1.1 409 Conflict

{ error: "Account already exists"}








        answered Aug 1, 2015 at 2:48
    




MvdD's user avatar






MvdDMvdD


21.9k8 gold badges63 silver badges91 bronze badges
        














That status code is for an HTTP error, not what you need.  Also, it would be very unhelpful as it does not describe the problem at all.


Why not just send:


Username already exists! Please select another.







        answered Aug 1, 2015 at 2:31
    




Lance's user avatar






LanceLance


3,8244 gold badges21 silver badges29 bronze badges
        








2






403 is an ok response in my opinion. 409 and 412 are also possible choices.





        answered Aug 1, 2015 at 2:43
    




Vic F's user avatar






Vic FVic F


1,1391 gold badge11 silver badges26 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
          










Источник








Цитата

					Сообщение от Egorik008

					Посмотреть сообщение


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




Молодец, создал метод проверяющий существование пользователя, теперь используй его

Как я понял по твоему коду, в начале обработчика события клика button2 сделай проверку, на возвращаемое значение твоего метода checkuser(), просто напиши








C#
















1
2
3
4
5





if(checkuser())
{
MessageBox.Show("Пользователь уже существует!");
return;
}


















Как ты видишь, я вызываю messageBox в проверке, если метод вернул true о том, что пользователь существует. Думаю идея твоего метода заключается в том, чтоб что-то проверить и дать ответ, а не самостоятельное определение поведения твоей программы. Обычно этим занимаются процедуры. После messageBox стоит выйти из обработчика события, ибо зачем продолжать программу, если пользователь уже существует, в твоём случае? Проверку на возвращаемое значения скинь на 32ю строку, то есть в самое начало работы обработчика события клика, чтоб избавиться от неудобных значений сразу, а из 72й строчки кода не забудь убрать вызов messagebox






Источник







  



                       
  





	









    
    
    
    



Возможно, вам также будет интересно:
 
		

  • Пользователь платит только абонентскую плату которая зависит от выбранного тарифного плана ошибка
    • 

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

  • Пользователь не авторизован код ошибки
    • 

  • Польза от использования агрегатов лексическая ошибка
    • 

  • Полчаса пролетели незаметно для нас ошибка

    •  

		

		



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

























    
    







    
    
    
    
            
    
            
    
            
    
                
    
                    0
                    0
                    голоса
    
                
    Рейтинг статьи
    
                
    
            
        
    
                    
    
                            
    
            
    
                
    
                                            
    
                             Подписаться
                            
                        
    
                                            
    
                                                
                    
    
                
    
                                                    
    
                                                    
    
                                
    Уведомить о 
    
                                
    
                                    
                                
    
                                                                    
                                                                    
    
                                    
                                
    
                                                            
    
                                                
    
                            
    
                                        
    
                                        
    
                        
    
                            
    
                                                                                                        
    
                                        guest                                    
    
                                                
                                        
    
                        
    
                    
    
                    
                                        
                    
                    
    
                        
    
                
                    
    
                        
    
                
    
                    
    
                        0 комментариев                    
    
                                        
    
                    
    
                                                    
    
                                
    
                                                        
    
                                
    
                                                        
    
                                                                        Старые
                                                                        
                                
    
                                                                            Новые
                                                                                Популярные
                                                                        
    
                            
    
                                                
    
                
    
                
    
                    
     Межтекстовые Отзывы                     
    
                    
    Посмотреть все комментарии