Hi all,
I've seem to have hit a bug in undertow when combining proxying and gzip.
I'm trying to use undertow as a reverse-proxy and also compressing the result when clients support it. Undertow-code below.
* Proxying without compressing works fine (curl -v localhost:8099/proxy)
* Compressing content that is not proxied works fine (curl -v --compress localhost:8099/local)
* Proxy and compression just hangs. Not even headers are received (curl -v --compress localhost:8099/proxy)
Trying to debug what's going on I found that the GzipStreamSinkConduit receives all content but is never flushed.
The call sequence for GzipStreamSinkConduit for proxied content is:
write(ByteBuffer src) - all context from the proxied app is written.
wakeupWrites() - which basically does nothing. Ends up in DeflatingStreamSinkConduit.queueWriteListener() which calls any WriteReadyHandlers but there are none.
Any clues?
My code to setup undertow:
final PathHandler pathHandler = Handlers.path();
pathHandler.addExactPath("/local", new HttpHandler() {
@Override
public void handleRequest(HttpServerExchange exchange) throws Exception {
exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
exchange.getResponseSender().send("Hello World"); }
});
pathHandler.addPrefixPath("/proxy",
new ProxyHandler(
final EncodingHandler handler =
new EncodingHandler(pathHandler, new ContentEncodingRepository()
.addEncodingHandler("gzip",
new GzipEncodingProvider(), 50,
Predicates.truePredicate()));
Undertow.builder()
.addHttpListener(8099, "0.0.0.0")
.setHandler(handler)
.build().start();
--
Br,
Martin Andersson
Purple Scout AB
+46 732 05 14 01