Skip to content

set result in ComposedLastHttpContent instead of being null #8721

Merged
normanmaurer merged 1 commit intonetty:4.1from
KowalczykBartek:bug-fix/decoded-null-result
Jan 21, 2019
Merged

set result in ComposedLastHttpContent instead of being null #8721
normanmaurer merged 1 commit intonetty:4.1from
KowalczykBartek:bug-fix/decoded-null-result

Conversation

@KowalczykBartek
Copy link
Copy Markdown
Contributor

Motivation:
I want to fix bug in vert.x project (eclipse-vertx/vert.x#2562) caused by ComposedLastHttpContent result being null. I don't know if it is intentional that this last decoded chuck in the issue returns null, but if not - I am providing fix for that.

Modification:

  1. Added new constructor in ComposedLastHttpContent allowing to pass DecoderResult
  2. set DecoderResult.SUCCESS for created ComposedLastHttpContent in HttpContentEncoder
  3. set DecoderResult.SUCCESS for created ComposedLastHttpContent in HttpContentDecoder

Result:
Fixes eclipse-vertx/vert.x#2562

cheers!

@netty-bot
Copy link
Copy Markdown

Can one of the admins verify this patch?

Copy link
Copy Markdown
Member

@normanmaurer normanmaurer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a unit test as well ?

@normanmaurer
Copy link
Copy Markdown
Member

@netty-bot test this please

@KowalczykBartek KowalczykBartek force-pushed the bug-fix/decoded-null-result branch 2 times, most recently from ac10f44 to 4539071 Compare January 16, 2019 22:17
@KowalczykBartek
Copy link
Copy Markdown
Contributor Author

I added tests (to existing) compression/encoding tests - but I was not able to test decompression/decoding. I will try tomorrow.

@normanmaurer
Copy link
Copy Markdown
Member

@netty-bot test this please

@KowalczykBartek
Copy link
Copy Markdown
Contributor Author

@normanmaurer so, should I add test for decompression/decoding ? because I see that you approved this already.

@normanmaurer
Copy link
Copy Markdown
Member

@KowalczykBartek if you can sure... that said if you are too busy its fine as well and we can do a followup.

@KowalczykBartek
Copy link
Copy Markdown
Contributor Author

KowalczykBartek commented Jan 17, 2019

No, I will do it today, please wait with merging.

update: I was not able to finish that test - cannot pass trailing headers in decompression, i will continue that tomorrow.

@normanmaurer
Copy link
Copy Markdown
Member

@KowalczykBartek let me know once done as I would like to include this in the next release if possible

@normanmaurer normanmaurer added this to the 4.1.33.Final milestone Jan 18, 2019
@KowalczykBartek
Copy link
Copy Markdown
Contributor Author

KowalczykBartek commented Jan 18, 2019

@normanmaurer I created test (that was challenging :D ). The only problem with that test is ... It do not pass, because my trailer is missing - after some debugging I noticed that it(trailer) is correctly parsed but at the end is ignored :(
HttpObjectDecoder in line 675 is decoding trailer, then it is trying to parse headers (?), if headerParsers return null, it ignores my trailer.

line = headerParser.parse(buffer);
if (line == null) {
    return null;
}

I modified slightly this code,

line = headerParser.parse(buffer);
if (line == null) {
    if(!trailer.trailingHeaders().isEmpty())
    {
        this.trailer = null;
        return trailer;
    }
    return null;
}

and my test pass - but for sure this change breaks other stuff :D I will try to understand HttpObjectDecoder, but maybe you see mistake that I done in my test (or there is a bug in parsing logic)?

Thanks in advance :)

@KowalczykBartek KowalczykBartek force-pushed the bug-fix/decoded-null-result branch from 0d747d5 to c46455e Compare January 19, 2019 18:38
@KowalczykBartek
Copy link
Copy Markdown
Contributor Author

KowalczykBartek commented Jan 19, 2019

yeah ! I figured out what was wrong - and pushed the change !

Question:
Can I say that it is a bug when HttpObjectDecoder cannot parse that:

assertTrue(channel.writeInbound(Unpooled.copiedBuffer("My-Trailer: 42", CharsetUtil.US_ASCII)));
assertTrue(channel.writeInbound(Unpooled.copiedBuffer("\r\n", CharsetUtil.US_ASCII)));
assertTrue(channel.writeInbound(Unpooled.copiedBuffer("\r\n\r\n", CharsetUtil.US_ASCII)));

but can parse that:

assertTrue(channel.writeInbound(Unpooled.copiedBuffer("My-Trailer: 42\r\n\r\n\r\n", CharsetUtil.US_ASCII)));

?

@normanmaurer
Copy link
Copy Markdown
Member

normanmaurer commented Jan 19, 2019 via email

@KowalczykBartek
Copy link
Copy Markdown
Contributor Author

I created an issue : #8736

@normanmaurer
Copy link
Copy Markdown
Member

@netty-bot test this please

@normanmaurer
Copy link
Copy Markdown
Member

@KowalczykBartek please fix the checkstyle errors:

13:35:18 /code/codec-http/src/test/java/io/netty/handler/codec/http/HttpContentDecoderTest.java:104:52: Unnecessary parentheses around expression.
13:35:18 /code/codec-http/src/test/java/io/netty/handler/codec/http/HttpContentDecoderTest.java:106: Line is longer than 120 characters (found 139).
13:35:18 Audit done.
13:35:18

Also please ensure you release all messages that implement ReferenceCounted

Signed-off-by: Kowalczyk <bkowalczyyk@gmail.com>
@KowalczykBartek KowalczykBartek force-pushed the bug-fix/decoded-null-result branch from c46455e to 9346cc0 Compare January 20, 2019 16:41
@KowalczykBartek
Copy link
Copy Markdown
Contributor Author

KowalczykBartek commented Jan 20, 2019

Fixed checkstyle errors (now no errors after mvn clean package) - btw sorry I forget about code-style :D

Also please ensure you release all messages that implement ReferenceCounted

Fixed, from what I understand only DefaultHttpContent has disposable content.

@normanmaurer
Copy link
Copy Markdown
Member

@netty-bot Test this please

@normanmaurer normanmaurer merged commit 83b286f into netty:4.1 Jan 21, 2019
@normanmaurer
Copy link
Copy Markdown
Member

@KowalczykBartek thanks a lot!

normanmaurer pushed a commit that referenced this pull request Jan 21, 2019
Motivation:
I want to fix bug in vert.x project (eclipse-vertx/vert.x#2562) caused by ComposedLastHttpContent result being null. I don't know if it is intentional that this last decoded chuck in the issue returns null, but if not - I am providing fix for that.

Modification:
* Added new constructor in ComposedLastHttpContent allowing to pass DecoderResult
* set DecoderResult.SUCCESS for created ComposedLastHttpContent in HttpContentEncoder
* set DecoderResult.SUCCESS for created ComposedLastHttpContent in HttpContentDecoder

Result:
Fixes eclipse-vertx/vert.x#2562
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug with HTTP trailers and GZIP compression?

3 participants