Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP compression skips handler completion and HTTP encoder #282

Closed
bclozel opened this issue Feb 13, 2018 · 0 comments
Closed

HTTP compression skips handler completion and HTTP encoder #282

bclozel opened this issue Feb 13, 2018 · 0 comments
Labels
type/bug A general bug
Milestone

Comments

@bclozel
Copy link
Member

bclozel commented Feb 13, 2018

Expected behavior

When creating an HTTP server and enabling HTTP compression with minResponseSize=2048

I expect the following behavior:

  • if the HTTP response size is > 2048, then the response should be compressed
  • if the HTTP response size is < 2048, then the response should not be compressed
  • in both cases, the response and connection lifecycle should be honored

Actual behavior

When starting a server like the following and requesting it with curl localhost:8080/:

NettyContext context = HttpServer
	.create(options -> options.compression(2048).port(8080))
	.newHandler((req, res) -> res.sendString(Mono.just("test")))
	.block();

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:

  1. filtered messages (i.e. FilterMessage instances) are written directly using ctx.write()
  2. this skips totally the HTTP encoding phase
  3. because of that, the LastHttpContent message is never emitted
  4. HttpServerHandler never gets that message and can't properly manage the lifecycle of the response

In contrast, when the response message is large enough:

  1. FilteringHttpContentCompressor is using non-filtered messages and delegates to HttpContentCompressor.write()
  2. which goes through the HTTP encoder and emits the LastHttpContent message
  3. 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants