HttpContentDecoder must continue read when it did not produce any mes…

[normanmaurer]

…sage and auto read is false

Motivation:

When HttpContentDecoder (and so HttpContentDecompressor) does not produce any message we need to make sure it calls ctx.read() if auto read is false to not stale.

Modifications:

• Keep track if we need to call ctx.read() or not
• Add unit test

Result:

Fixes #8915.

[ejona86]

Why isn't this part of MessageToMessageDecoder?

[ejona86]

I think this variable handling is inverted. needRead should start as true, and if !out.isEmpty() it should be set to false. Then in channelReadComplete() it should be set to true again.

If a read() causes three ByteBufs to be read (because using DefaultMaxBytesRecvByteBufAllocator), which calls decode() three times, the first two times may not put anything in out but the last decode does place something in out. It seems in that case we shouldn't call read.

But there's also the case where the second bytebuf placed something in out. That seems like it shouldn't call read either.

[normanmaurer]

@ejona86 sure why not.

[normanmaurer]

@ejona86 its not mark of MessageToMessageDecoder because we messed in the past and allowed it to be @Sharable. In the next major release we should fix this but there is nothing we can do there for now :(

[andreisilviudragnea]

I can confirm too that #8915 is fixed by these changes. I have also understood now how the Inflater used behind the scenes by JdkZlibDecoder decompresses as much as it can from the input buffer, passing the output on. Initially, I thought JdkZlibDecoder also uses the accumulator buffer approach like the ByteToMessageDecoder Thank you for the quick fix! 😄