Re[6]: обработка ошибок
От: Ночной Смотрящий Россия  
Дата: 11.04.22 16:06
Оценка: 5 (1) +1
Здравствуйте, yenik, Вы писали:

Y>В стандарте одно, а в жизни другое.


В стандарте все хорошо, там нет ничего ни про какое время.

The 4xx class of status code is intended for cases in which the client seems to have erred.

RFC2616.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[8]: обработка ошибок
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 11.04.22 16:19
Оценка: +4
Здравствуйте, yenik, Вы писали:

Y>Здесь возврат 400 для запроса, некорректного с точки зрения бизнес-логики. Запрос, который некорректен сегодня, может стать корректным завтра. И тогда его можно смело повторить и он вернёт 200.

Падажжите. Там речь идёт о некорректном токене, переданном с клиента. 4хх здесь — то, что доктор прописал.
5хх означает "да, вы всё правильно попросили, я должен был сделать то, что вы просите, но не смог".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[7]: обработка ошибок
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.04.22 16:35
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, yenik, Вы писали:


Y>>В стандарте одно, а в жизни другое.


НС>В стандарте все хорошо, там нет ничего ни про какое время.

НС>

НС>The 4xx class of status code is intended for cases in which the client seems to have erred.

НС>RFC2616.

Это смотря что считать ошибкой клиента. Передача номера счета, которого нет — ошибка клиента и надо вернуть 400 или все-таки 500?
Re[8]: обработка ошибок
От: Ночной Смотрящий Россия  
Дата: 11.04.22 17:16
Оценка: +4
Здравствуйте, gandjustas, Вы писали:

G>Это смотря что считать ошибкой клиента. Передача номера счета, которого нет — ошибка клиента и надо вернуть 400 или все-таки 500?


Очень странный вопрос. Конечно 4хх.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re: обработка ошибок
От: vaa https://www.youtube.com/playlist?list=PLtrvASfI1KW7VOYRKjglcagQzWLoxlncl
Дата: 12.04.22 05:47
Оценка:
Здравствуйте, MadHuman, Вы писали:

MH>было подобное? какое решение находили?..


Все определяется архитектурой фрэймворка.
в данном случае есть стандартные NotFound(), OkObject(..) и т.д.
выбрасывать исключение, которого ожидали неоправданно.
Re[9]: обработка ошибок
От: yenik  
Дата: 12.04.22 11:31
Оценка: +1
Y>>Здесь возврат 400 для запроса, некорректного с точки зрения бизнес-логики. Запрос, который некорректен сегодня, может стать корректным завтра. И тогда его можно смело повторить и он вернёт 200.
S>Падажжите. Там речь идёт о некорректном токене, переданном с клиента. 4хх здесь — то, что доктор прописал.
S>5хх означает "да, вы всё правильно попросили, я должен был сделать то, что вы просите, но не смог".

Может быть, я всё неправильно понимаю. Просветите меня.

https://datatracker.ietf.org/doc/html/rfc2616#section-10.4.1

10.4.1 400 Bad Request

The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without
modifications.


Однако, в моём примере запрос имеет безупречный синтаксис и прекрасно понимается. Просто была запрошена сущность, которая пока/уже не существует.
Если открыть админскую панель и завести таковую сущность, то тот же самый запрос можно смело повторить и получить код 200.
Re[10]: обработка ошибок
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 12.04.22 11:52
Оценка: 5 (1) +1
Здравствуйте, yenik, Вы писали:

Y>Может быть, я всё неправильно понимаю. Просветите меня.

Ага.
Y>https://datatracker.ietf.org/doc/html/rfc2616#section-10.4.1

Y>

Y>10.4.1 400 Bad Request

Y> The request could not be understood by the server due to malformed
Y> syntax. The client SHOULD NOT repeat the request without
Y> modifications.


Y>Однако, в моём примере запрос имеет безупречный синтаксис и прекрасно понимается. Просто была запрошена сущность, которая пока/уже не существует.

Фейл по вине клиента — это 4xx. Не обязательно прямо 400.
Если сущности ещё не существует — 404 Not Found
Если уже не существует — 410 Gone
Y>Если открыть админскую панель и завести таковую сущность, то тот же самый запрос можно смело повторить и получить код 200.
Но если не заводить, то никаких 200 вы не получите.
500 означает, что запрос возможно сработает когда-то ещё, даже если в админскую панель не заходить и ничего не крутить.
Для сравнения — 403 Access Denied не означает, что доступ закрыт навсегда. Если пойти в админскую панель и выдать разрешение, то можно смело повторить запрос и получить 200.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[10]: обработка ошибок
От: MadHuman Россия  
Дата: 12.04.22 17:26
Оценка: 2 (1)
Здравствуйте, yenik, Вы писали:


Y>Может быть, я всё неправильно понимаю. Просветите меня.


Y>https://datatracker.ietf.org/doc/html/rfc2616#section-10.4.1


Y>

Y>10.4.1 400 Bad Request

Y> The request could not be understood by the server due to malformed
Y> syntax. The client SHOULD NOT repeat the request without
Y> modifications.


для 400 расширилась трактовка — здесь

The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something
that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)


так что, норм 400 если синтаксис ок, но сами данные невалидны с точки зрения сервера.
причем ещё для такого кейса вполне ок и 422, но с одной стороны он вроде как бы был специфичен для WebDAV
и я не понял, есть ли однозначный консенсус не нему на текущий момент.
но 400 точно ок.
Отредактировано 12.04.2022 17:35 MadHuman . Предыдущая версия .
Re[11]: обработка ошибок
От: yenik  
Дата: 13.04.22 07:26
Оценка:
S>Фейл по вине клиента — это 4xx. Не обязательно прямо 400.
S>Если сущности ещё не существует — 404 Not Found
S>Если уже не существует — 410 Gone
Y>>Если открыть админскую панель и завести таковую сущность, то тот же самый запрос можно смело повторить и получить код 200.
S>Но если не заводить, то никаких 200 вы не получите.
S>500 означает, что запрос возможно сработает когда-то ещё, даже если в админскую панель не заходить и ничего не крутить.
S>Для сравнения — 403 Access Denied не означает, что доступ закрыт навсегда. Если пойти в админскую панель и выдать разрешение, то можно смело повторить запрос и получить 200.

Похоже, мы потеряли нить рассуждения.

Меня заинтересовало вот это сообщение.
http://rsdn.org/forum/dotnet/8252769.1
Автор: gandjustas
Дата: 08.04 15:20

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


Однако мы говорим, что 400 можно и нужно кидать для ситуаций, которые могут меняться со временем.

https://datatracker.ietf.org/doc/html/rfc2616#section-10.4.1

10.4.1 400 Bad Request

The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without
modifications.


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

Тут коллега сделал хорошее замечание.
http://rsdn.org/forum/dotnet/8255491.1
Автор: MadHuman
Дата: 12.04 20:26

для 400 расширилась трактовка


И действительно, смотрим https://www.rfc-editor.org/rfc/rfc7231#section-6.5.1

6.5.1. 400 Bad Request

The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).


Здесь уже не сказано, что клиенту не следует повторять запрос. И даётся примерный список причин для 400: malformed request syntax, invalid request message framing, or deceptive request routing.
Но это всё технические проблемы, а не бизнес-процесс. Однако лично я согласен, что ограничения бизнес-процесса тоже годятся.
Re[12]: обработка ошибок
От: Ночной Смотрящий Россия  
Дата: 13.04.22 07:33
Оценка: +1
Здравствуйте, yenik, Вы писали:

Y>Однако мы говорим, что 400 можно и нужно кидать для ситуаций, которые могут меняться со временем.


Нюанс тут, что альтернативой 400 предлагается 500

G>>Это означает, что 400 нельзя кидать для ситуаций, которые могут меняться со временем и для любых rntime эксепшенов.
Б>Все равно это должна быть какая-то ошибка 4xx, а не 5xx
G>Почему? И какая?


Конкретно 400 может и не лучший вариант (есть и 404, и 409 и много чего еще, что может со временем поменяться), но 500 это точно ни в какие ворота.

Y>Тут коллега сделал хорошее замечание.

Y>http://rsdn.org/forum/dotnet/8255491.1
Автор: MadHuman
Дата: 12.04 20:26

Y>

Y>для 400 расширилась трактовка


Она просто стала адекватной де-факто использованию для API. Потому что набор стандартных 4хх далеко не исчерпывающий, и если ни один из них не подходит — используют 400.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[13]: обработка ошибок
От: yenik  
Дата: 13.04.22 07:38
Оценка:
НС>Нюанс тут, что альтернативой 400 предлагается 500
НС>

G>>>Это означает, что 400 нельзя кидать для ситуаций, которые могут меняться со временем и для любых rntime эксепшенов.
Б>>Все равно это должна быть какая-то ошибка 4xx, а не 5xx
G>>Почему? И какая?


НС>Конкретно 400 может и не лучший вариант (есть и 404, и 409 и много чего еще, что может со временем поменяться), но 500 это точно ни в какие ворота.


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

Y>>Тут коллега сделал хорошее замечание.

Y>>http://rsdn.org/forum/dotnet/8255491.1
Автор: MadHuman
Дата: 12.04 20:26

Y>>

Y>>для 400 расширилась трактовка


НС>Она просто стала адекватной де-факто использованию для API. Потому что набор стандартных 4хх далеко не исчерпывающий, и если ни один из них не подходит — используют 400.


Воистину. Но это стало понятно не сразу.
Re[12]: обработка ошибок
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 13.04.22 08:11
Оценка: 5 (1) +1
Здравствуйте, yenik, Вы писали:

Y>Меня заинтересовало вот это сообщение.

Y>http://rsdn.org/forum/dotnet/8252769.1
Автор: gandjustas
Дата: 08.04 15:20

Y>

Y>Про 400 и 500 это был провокационный вопрос.
Y>Ответ в стандарте — если клиент получает 400, то он не должен пытаться повторить запрос с теми же параметрами.
Y>Это означает, что 400 нельзя кидать для ситуаций, которые могут меняться со временем и для любых rntime эксепшенов.


Y>Однако мы говорим, что 400 можно и нужно кидать для ситуаций, которые могут меняться со временем.

Да, в том сообщении была приведена слишком жёсткая формулировка. Имеется в виду — самопроизвольно меняться со временем.

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

Y>Или что тогда означает malformed syntax?
Вы напрасно пытаетесь найти сакральный смысл в дословном переводе примеров ошибок клиента. 400 — это любая ошибка клиента, для которой нет более специфичного 4xx-кода.

Y>Здесь уже не сказано, что клиенту не следует повторять запрос. И даётся примерный список причин для 400: malformed request syntax, invalid request message framing, or deceptive request routing.

Y>Но это всё технические проблемы, а не бизнес-процесс. Однако лично я согласен, что ограничения бизнес-процесса тоже годятся.
Дело не столько в ограничениях бизнес-процесса. Вопрос в том, кто именно допустил ошибку — клиент или сервер.
К примеру, если вы делаете сервис перевода денег со счёта на счёт, то способов сделать ошибку — много.
Самое простое — напороть в формате. Допустим, вы передали какой-то мусор вместо номера счёта или суммы для перевода. Это совершенно точно должно быть ошибкой 400, а не 5xx из-за исключения, вылетевшего из Decimal.Parse().
Затем — более интересные штуки. Например, номер счёта по формату валиден, но счёта такого нет. Опять — мы не перехватываем NullReferenceException с отдачей 500, а возвращаем 404.
Важное решение — как обрабатывать безопасность. Допустим, есть простое правило — счёт-источник должен принадлежать текущему пользователю. Мы могли бы возвращать 403 при нарушении этого правила. Но, быть может, мы захотим отдавать 404, чтобы не давать способа проверки существования счёта посторонним.

Вернёмся к ошибкам. Можно ли указывать один и тот же счёт в качестве источника и приёмника? Если нельзя — то это тоже 400.
То же самое — если на счету не хватает средств.

И так далее. 5хх означает, что сервер собирался выполнить запрос, но не смог.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[14]: обработка ошибок
От: Ночной Смотрящий Россия  
Дата: 13.04.22 08:31
Оценка: +1
Здравствуйте, yenik, Вы писали:

Y>Я бы сказал, что общепринятые коды ошибок вообще несколько отстали от жизни.


А я бы не сказал. Есть некоторый бардак в использовании кодов от WebDAV, но это мелочи.
Тут надо понимать, что кодов возврата, любых, все равно недостаточно. И нужен все равно некий идентификатор ошибки, например что то типа type в RFC 7807. И на него должна полагаться клиентская логика. А именно коды нужны не столько для клиентской логики, сколько для инфраструктуры — браузера с кешами и окошками ввода паролей, интеллектуальных проксей и роутеров и т.п. И в этом плане существующих кодов вполне достаточно, пока не появится какой то новый с точки зрения инфраструктуры сценарий.
Для примера — в текущем проекте анализа именно статуса можно пересчитать по пальцам одной руки. Самый частый — это флажок notFoundAsDefault в базовом клиенте. Если он установлен в true, то возврат 404 приводит к возврату default из метода, а если false — к выбросу исключения.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[12]: обработка ошибок
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 13.04.22 08:37
Оценка:
Здравствуйте, yenik, Вы писали:

Y>Меня заинтересовало вот это сообщение.

Y>http://rsdn.org/forum/dotnet/8252769.1
Автор: gandjustas
Дата: 08.04 15:20

Y>

Y>Про 400 и 500 это был провокационный вопрос.
Y>Ответ в стандарте — если клиент получает 400, то он не должен пытаться повторить запрос с теми же параметрами.
Y>Это означает, что 400 нельзя кидать для ситуаций, которые могут меняться со временем и для любых rntime эксепшенов.


Y>Однако мы говорим, что 400 можно и нужно кидать для ситуаций, которые могут меняться со временем.

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

Иначе можно дойти до того, что надо 500 кидать вместо 404 при отсутствии ресурса, ведь через секунду кто-то может сделать PUT на этот адрес и создать ресурс.
Re[13]: обработка ошибок
От: Ночной Смотрящий Россия  
Дата: 13.04.22 09:24
Оценка:
Здравствуйте, gandjustas, Вы писали:

Y>>Однако мы говорим, что 400 можно и нужно кидать для ситуаций, которые могут меняться со временем.

G>Конечно речь об изменениях, которые происходят независмо от запросов клиента.

А 403 или там 409 можно? Или только 500?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[15]: обработка ошибок
От: yenik  
Дата: 15.04.22 08:15
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, yenik, Вы писали:


Y>>Я бы сказал, что общепринятые коды ошибок вообще несколько отстали от жизни.


НС>А я бы не сказал. Есть некоторый бардак в использовании кодов от WebDAV, но это мелочи.

НС>Тут надо понимать, что кодов возврата, любых, все равно недостаточно. И нужен все равно некий идентификатор ошибки, например что то типа type в RFC 7807. И на него должна полагаться клиентская логика. А именно коды нужны не столько для клиентской логики, сколько для инфраструктуры — браузера с кешами и окошками ввода паролей, интеллектуальных проксей и роутеров и т.п. И в этом плане существующих кодов вполне достаточно, пока не появится какой то новый с точки зрения инфраструктуры сценарий.

О том и речь. Для клиентских приложений коды неадекватны. Хотя задумывались они в те времена, когда интеллектуальные прокси были ещё не в ходу, и коды предназначались для клиентов.
Re[13]: обработка ошибок
От: yenik  
Дата: 15.04.22 08:31
Оценка:
Y>>Меня заинтересовало вот это сообщение.
Y>>http://rsdn.org/forum/dotnet/8252769.1
Автор: gandjustas
Дата: 08.04 15:20

Y>>

Y>>Про 400 и 500 это был провокационный вопрос.
Y>>Ответ в стандарте — если клиент получает 400, то он не должен пытаться повторить запрос с теми же параметрами.
Y>>Это означает, что 400 нельзя кидать для ситуаций, которые могут меняться со временем и для любых rntime эксепшенов.


Y>>Однако мы говорим, что 400 можно и нужно кидать для ситуаций, которые могут меняться со временем.

S>Да, в том сообщении была приведена слишком жёсткая формулировка.

Просто неправильная — "нельзя" вместо "можно и нужно". И "для любых rntime эксепшенов" — тоже неверно.

S>Имеется в виду — самопроизвольно меняться со временем.


Самопроизвольно — это как спонтанное деление атомов?

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

Y>>Или что тогда означает malformed syntax?
S>Вы напрасно пытаетесь найти сакральный смысл в дословном переводе примеров ошибок клиента. 400 — это любая ошибка клиента, для которой нет более специфичного 4xx-кода.

Вы напрасно приписываете мне поиск чего-то сакрального. Как раз наоборот, я указываю на несакральность RFC.

S>Вернёмся к ошибкам. Можно ли указывать один и тот же счёт в качестве источника и приёмника? Если нельзя — то это тоже 400.

S>То же самое — если на счету не хватает средств.

S>И так далее. 5хх означает, что сервер собирался выполнить запрос, но не смог.


Если на счету не хватает средств — это как раз и означает, что сервер собирался, но не смог.
Re[16]: обработка ошибок
От: Ночной Смотрящий Россия  
Дата: 15.04.22 10:40
Оценка: +1
Здравствуйте, yenik, Вы писали:

Y>О том и речь. Для клиентских приложений коды неадекватны. Хотя задумывались они в те времена, когда интеллектуальные прокси были ещё не в ходу, и коды предназначались для клиентов.


Ты зря так думаешь. К примеру, логика кеширования задумывалась на очень ранних этапах развития HTTP, и она уже по полной опирается на статускоды.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[14]: обработка ошибок
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 16.04.22 02:07
Оценка:
Здравствуйте, yenik, Вы писали:

Y>Просто неправильная — "нельзя" вместо "можно и нужно". И "для любых runtime эксепшенов" — тоже неверно.

Нет.

S>>Имеется в виду — самопроизвольно меняться со временем.

Y>Самопроизвольно — это как спонтанное деление атомов?
Это как без изменения состояния приложения. То есть, к примеру, кончилось место на диске — и сервер выдаёт 500. Потом приходит админ, чистит логи, и сервер начинает работать.
Состояние приложения — не изменилось. Изменилось состояние сервера.
Или, к примеру, кто-то шаловливыми ручками полазил в сервере, с одного из фолдеров слетели пермиссии. Пока админ не вставит пермиссии на место, само ничего не заработает — но эти пермиссии не являются частью состояния приложения, поэтому возвращаем 500.
А вот если, скажем, у пользователя отобраны права на какой-то объект приложения, например на какой-то форум, то мы отдаём 403, а не 500. Потому что для того, чтобы ситуация изменилась, недостаточно перезапустить инсталлятор, или восстановиться из бэкапа, или почистить диск.

Y>Вы напрасно приписываете мне поиск чего-то сакрального. Как раз наоборот, я указываю на несакральность RFC.

Тогда зачем вы сосредотачиваетесь на трактовке malformed syntax?

S>>И так далее. 5хх означает, что сервер собирался выполнить запрос, но не смог.

Y>Если на счету не хватает средств — это как раз и означает, что сервер собирался, но не смог.
Нет. Даже и не собирался. Это не сервер не смог, это состояние приложения не позволяет продолжать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[15]: обработка ошибок
От: yenik  
Дата: 20.04.22 07:17
Оценка:
Y>>Просто неправильная — "нельзя" вместо "можно и нужно". И "для любых runtime эксепшенов" — тоже неверно.
S>Нет.


Y>>Вы напрасно приписываете мне поиск чего-то сакрального. Как раз наоборот, я указываю на несакральность RFC.

S>Тогда зачем вы сосредотачиваетесь на трактовке malformed syntax?
Уже ответил.

S>>>И так далее. 5хх означает, что сервер собирался выполнить запрос, но не смог.

Y>>Если на счету не хватает средств — это как раз и означает, что сервер собирался, но не смог.
S>Нет. Даже и не собирался. Это не сервер не смог, это состояние приложения не позволяет продолжать.

Ах вот о чём речь, сервер отдельно, а приложение отдельно. Да, причин для отказа сервера может быть бесчисленное множество, но мы не будем их рассматривать, речь не об этом.
В случае с нехваткой средств сервер как раз собирался и смог, и вернул код из приложения.
Таким образом, если на счету не хватает средств, то должен быть возвращён код 400. И это ситуация, которая поменяется со временем. В следующий раз средств хватит и, и запрос выполнится успешно. И это противоречит утверждению:

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


Остаётся вопрос, можем ли мы обобщить это так, что любые ошибки приложения (кроме отказов инфраструктуры) должны возвращать 4хх?
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.