more fixes

i2p2www/pages/site/docs/api/streaming.html

@@ -463,13 +463,15 @@ TCP headers include the receive window in bytes; however,
 the streaming protocol does not provide a way to exchange max receive window size either in bytes or packets.
 There is only a simple choke/unchoke indication indicating that the receive buffer is full.
 Each endpoint must maintain its own estimate of the far-end receive window, in either bytes or packets.
+Note that a receive buffer may overflow at any window size if the
+client application is slow to empty the buffer.
 </p><p>
 The default maximum transmit and receive window size in the Java implementation is 128 packets.
 Implementations setting a maximum transmit window size higher than 128
 must consider the following issues:
 </p>
 <ul>
-<li>CHOKE responses from Java routers due to receive buffer overflow are must more likely.
+<li>CHOKE responses from Java routers due to receive buffer overflow are much more likely.
 <li>Far-end receiver buffer size estimation must be implemented to mitigate repeated overflows (see above)
 <li>CHOKE must be handled correctly (see below)
 <li>Max window sizes over 256 are even more error-prone, because the nack count option field length