Здравствуйте, okman, Вы писали:
Упс, мой длинный ответ на предыдущий вариант поста пропал
O>2xx — запрос обработан бэк эндом. Клиент переходит к формированию и отправке следующего.
O>4xx может означать только некорректно сформированные на уровне HTTP данные.
O>5xx — сервер недоступен, запрос следует повторить позже.
O>Все ясно, как день.
Не, неясно. Вы только что писали, что неправильно сформированный запрос возвращает 200 Ok. С точки зрения сервера, он ничуть не лучше ошибки в урле или глаголе — запрос выполнить так и не удалось. Тем не менее клиент уверен, что можно ехать дальше. Вижу противоречие.
O>Да, все верно. На уровне HTTP мы используем сжатие, кэширование, даже контроль целостности.
O>А уровень данных играет по своим правилам. Я лишь предлагаю не смешивать их воедино, а
O>аккуратно изолировать друг от друга. При этом разница насколько тонкая, что остается
O>почти незаметной. Фактически, все различия сводятся только к тому, чтобы не использовать на
O>уровне данных (HTML/JSON/XML/другое) механизмы из нижележащего уровня (HTTP/TCP/UDP/другое),
O>такие как коды состояний или опции сжатия, а оставить их на совести того самого уровня, который ниже.
O>Впечатление, будто я призываю отказываться от встроенных механизмов HTTP — в корне неверное.
Вы почему-то ставите "уровень данных" выше "уровня HTTP". Реальный прикладной протокол описывает всё сразу — и набор глаголов, и набор существительных. Нельзя сказать, что что-то одно "выше уровнем", чем что-то другое.
Вон Geri по соседству спрашивает — кто должен обрабатывать Conditional GET? Кто должен обрабатывать Partial Get?
Кто должен анализировать Accept- хидеры?
O>Это вовсе не так. Прокомментировал выше.
Однако с кодами статусов вы дела иметь почему-то не хотите. Странно.
O>Давайте рассмотрим еще один (очень упрощенный) пример.
O>Допустим, есть веб-сервис покупок, через который я POST-запросом могу заказать себе, скажем,
O>ящик водки. При успешном заказе сервер возвращает 200 OK, а с моего счета списывается некая сумма.
O>В определенный момент мой баланс становится нулевым и денег на водку не хватает — на очередной
O>запрос сервер должен возвратить что ? "200 OK" или "400 Bad Request" ? Допустим, первый вариант.
O>Объясните, почему прокси вдруг должен закэшировать ответы с кодом 200, но при этом передавать
O>ответы с кодом 400 мимо кэша ? Требование идемпотентности к запросам POST не предъявляется.
O>А по поводу кода 400 в RFC 2616 сказано: "The client SHOULD NOT repeat the request without
O>modifications" — клиенту не рекомендуется повторять тот же самый запрос, не включив в него
O>модификации. Как раз в этом случае прокси с большей вероятностью закэширует ответ-400 на
O>один и тот же запрос и будет все время его возвращать.
Нет. По поводу кода надо читать раздел 13.4. По поводу POST — раздел 9.5. При прочих равных вероятность кэширования 200 выше, т.к. она требует от прокси нарушать только один пункт RFC, а кэширование 400 — сразу два.
Сам выбранный вами протокол для покупки является антипримером. Вы выбрали самый неудачный из глаголов HTTP для реализации потенциально опасной операции. Вот получите вы таймаут на клиенте — как вам понять, списались деньги или ещё нет? Освойте идемпотентность — это единственное решение проблемы двух генералов.
O>У нас разное понимание семантики кода 200.
O>Я считаю, что код 200 — это "запрос обработан". Или, точнее говоря, "сообщение доставлено".
O>Что это за запрос и что это за сообщение — уже не забота HTTP.
Очень странная позиция. Вопросу о том, "что это за сообщение", посвящён целый раздел №9.
HTTP не сводится к "доставке сообщений". Он ещё и подразумевает некоторую семантику. И если её не удалось обеспечить, то сервер обязан вернуть соотвествующий статус.
O>Ошибка транспорта — это когда в GET-запросе не указывается URL или Host.
O>Логическая ошибка — это когда я пытаюсь заказать водку, а денег на счету нет.
Отлично. И чем эта ошибка хуже той, когда я пытаюсь заказать водку, а водки нет?
А эта — чем когда я пытаюсь скачать фотку водки, а фотки нет?
Почему-то в этих случаях принято возвращать 404, а не 200 Фото не найдено.
O>Код из группы 500, понятное дело. Запрос не был обработан бэк эндом, для клиента
O>это достаточная для принятия нужного решения информация.
Что вы называете "бэк-ендом"? Сообщение было "доставлено" ажно до обработчика в ASP.Net — куда дальше-то.
И бэк-енд там что-то наобрабатывал. Вплоть до момента вылета. C точки зрения фронтенда всё хорошо.
