Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, okman, Вы писали:
S>Упс, мой длинный ответ на предыдущий вариант поста пропал

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

S>Вы только что писали, что неправильно сформированный запрос возвращает 200 Ok.

Нигде я такого не писал.

S>Вы почему-то ставите "уровень данных" выше "уровня HTTP". Реальный прикладной протокол описывает всё сразу — и набор глаголов, и набор существительных. Нельзя сказать, что что-то одно "выше уровнем", чем что-то другое.

HTTP выше TCP. Так пойдет ?

S>Вон Geri по соседству спрашивает — кто должен обрабатывать Conditional GET? Кто должен обрабатывать Partial Get?
S>Кто должен анализировать Accept- хидеры?

Тот, кто и всегда.

S>Однако с кодами статусов вы дела иметь почему-то не хотите. Странно.

Я против перегрузки кодов состояний HTTP значениями логических ошибок веб-сервиса.
Например, когда "400 Bad Request" может означать какой-нибудь некорректный URL в строке запроса,
что на счету клиента недостаточно средств и что "мы по субботам не работаем".
Во-первых, чтобы отличить эти ошибки одна от другой, клиенту придется лезть в тело ответа,
возиться с gzip-ом и кодировками, а потом разбираться, что имел в виду сервер.
Во-вторых, представьте систему, где сервер может возвращает два и более статуса.
Например, статус успеха плюс предупреждение. Как это все будет накладываться на HTTP ?
Будем изобретать вторую статусную строку или новые заголовки ?

S>По поводу кода надо читать раздел 13.4. По поводу POST — раздел 9.5. При прочих равных вероятность кэширования 200 выше, т.к. она требует от прокси нарушать только один пункт RFC, а кэширование 400 — сразу два.
S>Сам выбранный вами протокол для покупки является антипримером. Вы выбрали самый неудачный из глаголов HTTP для реализации потенциально опасной операции. Вот получите вы таймаут на клиенте — как вам понять, списались деньги или ещё нет? Освойте идемпотентность — это единственное решение проблемы двух генералов.

А при чем тут идемпотентность вообще ?
У меня может рухнуть сеть между отправкой сервером ответа и приемом его на клиенте.
К рассматриваемому вопросу это вообще не относится. Проблема будет в любом случае, верну я код 200 или 400.

S>Очень странная позиция.

Потому что она не совпадает с Вашей ?

S>Вопросу о том, "что это за сообщение", посвящён целый раздел №9.
S>HTTP не сводится к "доставке сообщений". Он ещё и подразумевает некоторую семантику. И если её не удалось обеспечить, то сервер обязан вернуть соотвествующий статус.

Мы ходим кругами вокруг одного и того же.
Семантика POST-запроса, в моем понимании, заключается в загрузке данных на сервер.
Плюс,

responses to this method are not cacheable, unless the response includes
appropriate Cache-Control or Expires header fields.

Сообщение доставлено ? Да.
Сервер обработал операцию ? Да. Все, работа POST на этом закончена, возвращаем 2xx.
То, что у Вас другая точка зрения, я в курсе, повторяться не стоит.

O>>Ошибка транспорта — это когда в GET-запросе не указывается URL или Host.
O>>Логическая ошибка — это когда я пытаюсь заказать водку, а денег на счету нет.

S>Отлично. И чем эта ошибка хуже той, когда я пытаюсь заказать водку, а водки нет?
S>А эта — чем когда я пытаюсь скачать фотку водки, а фотки нет?
S>Почему-то в этих случаях принято возвращать 404, а не 200 Фото не найдено.

Вы предлагаете совмещать в одном статусе 404 все три ответа — "фото не найдено",
"нет водки на складе" и "запрашиваемый URL не найден", причем с разных логических уровней ?
Это основное, против чего я выступаю.

S>Что вы называете "бэк-ендом"? Сообщение было "доставлено" ажно до обработчика в ASP.Net — куда дальше-то.
S>И бэк-енд там что-то наобрабатывал. Вплоть до момента вылета. C точки зрения фронтенда всё хорошо.

Нет, не все. Потому что запрос не был обработан и фронт энд не может сформировать для клиента
полноценный ответ. Поэтому ему придется отдать код 500.

Дальнейшее обсуждение представляется мне бессмысленным.