Cater for empty response bodies when performing response compression.

Motivation:
RFC 2616, 4.3 Message Body states that:
All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a
message-body. All other responses do include a message-body, although it MAY be of zero length.

Modifications:
HttpContentEncoder was previously modified to cater for HTTP 100 responses. This check is enhanced to
include HTTP 204 and 304 responses.

Result:
Empty response bodies will not be modified to include the compression footer. This footer messed with Chrome's
response parsing leading to "hanging" requests.
This commit is contained in:
Roelof Naude 2014-11-10 12:57:02 +02:00 committed by Norman Maurer
parent 278a5a397a
commit d220afa885

View File

@ -87,7 +87,12 @@ public abstract class HttpContentEncoder extends MessageToMessageCodec<HttpReque
final HttpResponse res = (HttpResponse) msg;
if (res.status().code() == 100) {
/*
* per rfc2616 4.3 Message Body
* All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a
* message-body. All other responses do include a message-body, although it MAY be of zero length.
*/
if (isPassthru(res)) {
if (isFull) {
out.add(ReferenceCountUtil.retain(res));
} else {
@ -174,6 +179,11 @@ public abstract class HttpContentEncoder extends MessageToMessageCodec<HttpReque
}
}
private static boolean isPassthru(HttpResponse res) {
final int code = res.status().code();
return code < 200 || code == 204 || code == 304;
}
private static void ensureHeaders(HttpObject msg) {
if (!(msg instanceof HttpResponse)) {
throw new IllegalStateException(