HttpObjectAggregator only set Content-Length is not already set.

[beckje01]

Motivation:
HEAD requests will have a Content-Length set that doesn't match the
actual length. So we only want to set Content-Length header if it isn't
already set.

Modifications:
If check around setting the Content-Length

Result:
A HEAD request will no correctly return the specified Content-Length
instead of the body length

[netkins]

AUTOMATED MESSAGE for ADMINS:
Please verify and accept the pull request.
To accept, say @netkins accept
To build again, say @netkins build
To whitelist the author, say @netkins whitelist

[normanmaurer]

@beckje01 you are right.. please adjust to only do this for HEAD requests....

From RFC:

The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.

[normanmaurer]

@netkins accept

[beckje01]

@normanmaurer I'm not sure how I can tell with just the FullHttpMessage what type of request was made to start. In most cases if a content-length is set it should be passed through unless it was chunked in which case the content-length header shouldn't be set at all.

I could specifically check if the content-length header is > 0 and the content size of the message is 0 and for that case not override the existing content-length header; that should cover the HEAD scenario correctly. Does that sound like the best option?

[normanmaurer]

@beckje01 use method():
https://github.com/netty/netty/blob/4.1/codec-http/src/main/java/io/netty/handler/codec/http/HttpRequest.java#L47

[beckje01]

I think I made this very confusing due to how I worded the first part of this, let my try rephrasing.

A HEAD request is made to some server and the response is sent to the HttpObjectAggregator in which case we just have a AggregatedFullHttpResponse which doesn't have the method available. The finishAggregation is called and even if the Content-Length header was set by the responding server the value is recalculated, this recalculation is probably a good thing most of the time and in the case of chunked encoding it is necessary but in the special case of HEAD we don't want to override what the server sent us.

[normanmaurer]

@beckje01 ah ok got it... yeah you are right your fix should be ok then! :)

[beckje01]

Any idea what that failure is on the build?

[normanmaurer]

@beckje01 need to investigate... not related to your change

[normanmaurer]

@beckje01 thanks... cherry-picked into 4.0 (0dca08a), 4.1 (5ba4fdf) and master (20f5974)

[beckje01]

@normanmaurer No thank you!