ср, 25 дек. 2019 г. в 23:20, Maxim Dounin <mdou...@mdounin.ru>:
> Hello! > > On Wed, Dec 25, 2019 at 02:58:15PM +0500, Илья Шипицин wrote: > > > ср, 25 дек. 2019 г. в 14:38, Sergey Kandaurov <pluk...@nginx.com>: > > > > > > > > > On 24 Dec 2019, at 23:35, Илья Шипицин <chipits...@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
_______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru