<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">ср, 25 дек. 2019 г. в 23:20, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On Wed, Dec 25, 2019 at 02:58:15PM +0500, Илья Шипицин wrote:<br>
<br>
> ср, 25 дек. 2019 г. в 14:38, Sergey Kandaurov <<a href="mailto:pluknet@nginx.com" target="_blank">pluknet@nginx.com</a>>:<br>
> <br>
> ><br>
> > > On 24 Dec 2019, at 23:35, Илья Шипицин <<a href="mailto:chipitsine@gmail.com" target="_blank">chipitsine@gmail.com</a>> wrote:<br>
> > ><br>
> > > привет!<br>
> > ><br>
> > > допустим, такая ситуация. есть POST запрос, у него есть хедеры и,<br>
> > собственно, тело запроса. мы отправили хедеры на бекенд, тело не успели<br>
> > отправить, и бекенд нам сделал TCP RST.<br>
> > ><br>
> > > должен ли такой POST повторно отправляться, если не указан<br>
> > non_idempotent ? (судя по моим экспериментам - не отправляется. но ведь<br>
> > тело не было отправлено ? значит мы должны попасть под условие, что такой<br>
> > запрос можно отправить повторно ?)<br>
> ><br>
> > Как только мы успешно установили соединение и перешли к отправке запроса<br>
> > (не важно, успели начать отправку тела или нет), запрос считается<br>
> > отправленным,<br>
> > т.к. в общем случае мы не знаем, был ли он обработан или нет.<br>
> ><br>
> <br>
> я предлагаю такую логику.<br>
> бекенд умеет отличать полностью полученный запрос от неполного запроса<br>
> (например, по Content-Length)<br>
> навряд ли бекенд будет обрабатывать неполностью полученный запрос<br>
> <br>
> и считать отправленными только полностью отправленные запросы<br>
<br>
Считать-то можно, но у бекенда может быть своё мнение по этому <br>
вопросу.  Каких-либо явных утверждений в RFC 2616 / RFC 7231, <br>
которые бы говорили о том, что так можно - я в своё время не <br>
нашёл.  И по факту так скорее всего нельзя, так как на тело <br>
бекенду во многих случаях может быть наплевать.<br></blockquote><div><br></div><div>есть достаточно странный кейс, когда отправляется POST без тела. не конкретно в наших приложениях, а в принципе.</div><div>я по некоторым разбирался, зачем так делают (ну то есть, можно же GET, но специально сделали POST). ответ меня поразил -</div><div>по RFC нельзя кешировать POST. ну и чтобы наверняка без кеша, мы выбрали POST )) ну а тело ... надо не надо было<br></div><div><br></div><div>в описанном выше случае, действительно, тело (запроса) не предполагалось. <br></div><div><br></div><div>если тело предполагается, но не было отправлено, допустим бекенд вменяемый, что вполне может быть. он запрос не обработал.</div><div>можно ретраить.</div><div><br></div><div>каких-то явных противоречий в этом не вижу<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Если хочется это место оптимизировать - проще всего это делать, <br>
явно указав, что повторно отправлять неидемпотентные запросы <br></blockquote><div><br></div><div>ретрай неидемпотентных запросов, это, например, запрос мог полностью уйти, и даже обработаться (но мы не знаем этого, просто</div><div>не дождались ответа). это не совсем то, чего бы хотелось.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
можно, и озаботившись защитой от дублирующихся запросов на уровне <br>
приложения.  Тем более, что в общем случае это в любом случае <br>
нужно делать, ибо защищаться от нажатия пользователем кнопки <br>
"отправить" по второму разу и/или кнопки refresh - тоже надо.<br></blockquote><div><br></div><div>да, вы правы. так действительно лучше. но приложения есть приложения, а разработчики есть разработчики.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div></div>