!htp #19528 HttpServerBluePrint: close connection on request entity cancellation

akka-docs/rst/java/http/client-side/connection-level.rst

@@ -53,6 +53,10 @@ The connection can also be closed by the server.
 An application can actively trigger the closing of the connection by completing the request stream. In this case the
 underlying TCP connection will be closed when the last pending response has been received.
 
+The connection will also be closed if the response entity is cancelled (e.g. by attaching it to ``Sink.cancelled()``)
+or consumed only partially (e.g. by using ``take`` combinator). In order to prevent this behaviour the entity should be
+explicitly drained by attaching it to ``Sink.ignore()``.
+
 
 Timeouts
 --------

akka-docs/rst/java/http/server-side/low-level-server-side-api.rst

@@ -130,6 +130,10 @@ connection. An often times more convenient alternative is to explicitly add a ``
 ``HttpResponse``. This response will then be the last one on the connection and the server will actively close the
 connection when it has been sent out.
 
+Connection will also be closed if request entity has been cancelled (e.g. by attaching it to ``Sink.cancelled()``)
+or consumed only partially (e.g. by using ``take`` combinator). In order to prevent this behaviour entity should be
+explicitly drained by attaching it to ``Sink.ignore()``.
+
 
 .. _serverSideHTTPS-java:
 

akka-docs/rst/java/stream/migration-guide-2.0-2.4-java.rst

@@ -156,3 +156,17 @@ Routing settings parameter name
 and were accessible via ``settings``. We now made it possible to configure the parsers
 settings as well, so ``RoutingSettings`` is now ``routingSettings`` and ``ParserSettings`` is
 now accessible via ``parserSettings``.
+
+Client / server behaviour on cancelled entity
+---------------------------------------------
+
+Previously if request or response were cancelled or consumed only partially
+(e.g. by using ``take`` combinator) the remaining data was silently drained to prevent stalling
+the connection, since there could still be more requests / responses incoming. Now the default
+behaviour is to close the connection in order to prevent using excessive resource usage in case
+of huge entities.
+
+The old behaviour can be achieved by explicitly draining the entity:
+
+   response.entity().getDataBytes().runWith(Sink.ignore())
+

akka-docs/rst/scala/http/client-side/connection-level.rst

@@ -55,6 +55,10 @@ The connection can also be closed by the server.
 An application can actively trigger the closing of the connection by completing the request stream. In this case the
 underlying TCP connection will be closed when the last pending response has been received.
 
+The connection will also be closed if the response entity is cancelled (e.g. by attaching it to ``Sink.cancelled``)
+or consumed only partially (e.g. by using ``take`` combinator). In order to prevent this behaviour the entity should be
+explicitly drained by attaching it to ``Sink.ignore``.
+
 
 Timeouts
 --------

akka-docs/rst/scala/http/low-level-server-side-api.rst

@@ -132,6 +132,10 @@ connection. An often times more convenient alternative is to explicitly add a ``
 ``HttpResponse``. This response will then be the last one on the connection and the server will actively close the
 connection when it has been sent out.
 
+Connection will also be closed if request entity has been cancelled (e.g. by attaching it to ``Sink.cancelled``)
+or consumed only partially (e.g. by using ``take`` combinator). In order to prevent this behaviour entity should be
+explicitly drained by attaching it to ``Sink.ignore``.
+
 
 .. _serverSideHTTPS:
 

akka-docs/rst/scala/stream/migration-guide-2.0-2.4-scala.rst

@@ -102,6 +102,19 @@ and were accessible via ``settings``. We now made it possible to configure the p
 settings as well, so ``RoutingSettings`` is now ``routingSettings`` and ``ParserSettings`` is
 now accessible via ``parserSettings``.
 
+Client / server behaviour on cancelled entity
+---------------------------------------------
+
+Previously if request or response were cancelled or consumed only partially
+(e.g. by using ``take`` combinator) the remaining data was silently drained to prevent stalling
+the connection, since there could still be more requests / responses incoming. Now the default
+behaviour is to close the connection in order to prevent using excessive resource usage in case
+of huge entities.
+
+The old behaviour can be achieved by explicitly draining the entity:
+
+   response.entity.dataBytes.runWith(Sink.ignore)
+
 Changed Sources / Sinks
 =======================