Re: повторная отправка POST запросов ?

[Илья Шипицин]

ср, 25 дек. 2019 г. в 23:20, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Wed, Dec 25, 2019 at 02:58:15PM +0500, Илья Шипицин wrote:
>
> > ср, 25 дек. 2019 г. в 14:38, Sergey Kandaurov <pluknet на nginx.com>:
> >
> > >
> > > > On 24 Dec 2019, at 23:35, Илья Шипицин <chipitsine на gmail.com> wrote:
> > > >
> > > > привет!
> > > >
> > > > допустим, такая ситуация. есть POST запрос, у него есть хедеры и,
> > > собственно, тело запроса. мы отправили хедеры на бекенд, тело не успели
> > > отправить, и бекенд нам сделал TCP RST.
> > > >
> > > > должен ли такой POST повторно отправляться, если не указан
> > > non_idempotent ? (судя по моим экспериментам - не отправляется. но ведь
> > > тело не было отправлено ? значит мы должны попасть под условие, что
> такой
> > > запрос можно отправить повторно ?)
> > >
> > > Как только мы успешно установили соединение и перешли к отправке
> запроса
> > > (не важно, успели начать отправку тела или нет), запрос считается
> > > отправленным,
> > > т.к. в общем случае мы не знаем, был ли он обработан или нет.
> > >
> >
> > я предлагаю такую логику.
> > бекенд умеет отличать полностью полученный запрос от неполного запроса
> > (например, по Content-Length)
> > навряд ли бекенд будет обрабатывать неполностью полученный запрос
> >
> > и считать отправленными только полностью отправленные запросы
>
> Считать-то можно, но у бекенда может быть своё мнение по этому
> вопросу.  Каких-либо явных утверждений в RFC 2616 / RFC 7231,
> которые бы говорили о том, что так можно - я в своё время не
> нашёл.  И по факту так скорее всего нельзя, так как на тело
> бекенду во многих случаях может быть наплевать.
>

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

в описанном выше случае, действительно, тело (запроса) не предполагалось.

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

каких-то явных противоречий в этом не вижу


>
> Если хочется это место оптимизировать - проще всего это делать,
> явно указав, что повторно отправлять неидемпотентные запросы
>

ретрай неидемпотентных запросов, это, например, запрос мог полностью уйти,
и даже обработаться (но мы не знаем этого, просто
не дождались ответа). это не совсем то, чего бы хотелось.



> можно, и озаботившись защитой от дублирующихся запросов на уровне
> приложения.  Тем более, что в общем случае это в любом случае
> нужно делать, ибо защищаться от нажатия пользователем кнопки
> "отправить" по второму разу и/или кнопки refresh - тоже надо.
>

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


>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20191226/2693dd0f/attachment.htm>