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

[Maxim Dounin]

Hello!

On Wed, Dec 25, 2019 at 02:58:15PM +0500, Илья Шипицин wrote:

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

Считать-то можно, но у бекенда может быть своё мнение по этому 
вопросу.  Каких-либо явных утверждений в RFC 2616 / RFC 7231, 
которые бы говорили о том, что так можно - я в своё время не 
нашёл.  И по факту так скорее всего нельзя, так как на тело 
бекенду во многих случаях может быть наплевать.

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

-- 
Maxim Dounin
http://mdounin.ru/