They are written on the first write that makes it to the
io.undertow.server.protocol.http.HttpResponseConduit. If you are using
content encoding this may not actually correspond to the first write
your application does, and if you are using output streams writes are
also buffered, so you need to either fill the buffer or call flush()
to force a write.
If you see that line being hit in AllowedContentEncodings then the
header should definitely be set, unless something is then clearing it.
On Sat, Jan 7, 2017 at 7:19 AM, Michael Grove <mike(a)stardog.com> wrote:
I'm using EncodingHandler for gzip encoding of responses and
I'm not seeing
the header on the client, but I have a breakpoint in AllowedContentEncodings
L95, and it's definitely hit, but I'm wondering if it's hit after the
initial part of the response is written so that header isnt ever sent.
My handler dispatches to a worker thread if need be, does the biz logic,
calls startBlocking on the exchange, sets the status code and other headers
like Content-Type, and then writes the results to the stream from
HttpServerExchange#getOutputStream before calling endExchange.
I can see the Content-Type header correctly set, but not Content-Encoding.
The javadocs say they're written when the first write is initiated, but I
have't managed to find where that is, specifically in relation to the
EncodingHandler. Hoping someone can point me in the right direction or with
any luck, have a guess at what I've messed up.
undertow-dev mailing list