<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Hello,<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">I may have missed something, but it was to my understanding that nginx continuously send data to clients, thus fill up buffers whil the client empties it at the same time (FIFO).<br>



</div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Thus, to me, backend upload was stopping when the allocated buffer(s) was(were) full, waiting for space being available in it(them).<br><br></div>



<div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">That is how/why, to my understanding (again), nginx was supposed to be able to handle slow clients.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">



The intuitive solution if it was to happen to me, would have been to reduce buffer(s) size + number to ensure they fill up quickier (and thus stop downloading from upstream with the same velocity).<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">


In the end, the computation of the 'lost' resource is done:<br>- in space with number of 'attackers' * num buffers * size buffer<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">


- in time with space calculated above / upstream sownloading speed (an average would be enough)<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Is not your patch redundant with existing capabilities?<br>


</div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">You just added another caluclation, competing with the one above, multiplying the above values per 10%. You could as much have reduced the settings above to meet the same result, could not you? Not talking about the risk of introducing vulnerabilities/instabilities with custom patch.<br>


<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">What if the attacker modifies its client to ensure downloading 50% of the file (thanks to his /dev/null)? Your patch becomes useless and the resources grow back to what they used to be... on the other hand, the standard way of having modified how you handle upstream data would have been resisting, whatever amount of data any client grabs.<br>


</div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">
What have I missed here?<br></div><div class="gmail_extra"><div><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div>




</div></div>