You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The response is as expected not compressed, but the response is not properly closed. We can see that with curl not displaying the response as expected on the CLI but waiting for the response to finish.
I traced this behavior back to FilteringHttpContentCompressor, since when the response is smaller than the configured size:
filtered messages (i.e. FilterMessage instances) are written directly using ctx.write()
this skips totally the HTTP encoding phase
because of that, the LastHttpContent message is never emitted
HttpServerHandler never gets that message and can't properly manage the lifecycle of the response
In contrast, when the response message is large enough:
FilteringHttpContentCompressor is using non-filtered messages and delegates to HttpContentCompressor.write()
which goes through the HTTP encoder and emits the LastHttpContent message
HttpServerHandler later gets that message and can properly manage the lifecycle of the response
Reactor Netty version
0.7.4.BUILD-SNAPSHOT
JVM version (e.g. java -version)
java version "1.8.0_162"
Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)
OS version (e.g. uname -a)
Darwin 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64 x86_64
The text was updated successfully, but these errors were encountered:
Expected behavior
When creating an HTTP server and enabling HTTP compression with
minResponseSize=2048
I expect the following behavior:
Actual behavior
When starting a server like the following and requesting it with
curl localhost:8080/
:The response is as expected not compressed, but the response is not properly closed. We can see that with curl not displaying the response as expected on the CLI but waiting for the response to finish.
I traced this behavior back to
FilteringHttpContentCompressor
, since when the response is smaller than the configured size:FilterMessage
instances) are written directly usingctx.write()
LastHttpContent
message is never emittedHttpServerHandler
never gets that message and can't properly manage the lifecycle of the responseIn contrast, when the response message is large enough:
FilteringHttpContentCompressor
is using non-filtered messages and delegates toHttpContentCompressor.write()
LastHttpContent
messageHttpServerHandler
later gets that message and can properly manage the lifecycle of the responseReactor Netty version
0.7.4.BUILD-SNAPSHOT
JVM version (e.g.
java -version
)java version "1.8.0_162"
Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)
OS version (e.g.
uname -a
)Darwin 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64 x86_64
The text was updated successfully, but these errors were encountered: