NETTY-420 HttpClientCodec doesn't handle HEAD requests with Transfer-Encoding: chunked responses

* Reverted back the workaround for servers that sends unnecessary zero-byte chunk in a HEAD response because it actually breaks the codec when the server that conforms to the RFC.

Author: trustin

src/main/java/org/jboss/netty/handler/codec/http/HttpClientCodec.java

@@ -136,11 +136,20 @@ protected boolean isContentAlwaysEmpty(HttpMessage msg) {
                 // message-body, even though the presence of entity-header fields
                 // might lead one to believe they do.
                 if (HttpMethod.HEAD.equals(method)) {
-                    // Interesting edge case:
-                    // Zero-byte chunk will appear if Transfer-Encoding of the
-                    // response is 'chunked'.  This is probably because of the
-                    // trailing headers.
-                    return !msg.isChunked();
+                    return true;
+
+                    // The following code was inserted to work around the servers
+                    // that behave incorrectly.  It has been commented out
+                    // because it does not work with well behaving servers.
+                    // Please note, even if the 'Transfer-Encoding: chunked'
+                    // header exists in the HEAD response, the response should
+                    // have absolutely no content.
+                    //
+                    //// Interesting edge case:
+                    //// Some poorly implemented servers will send a zero-byte
+                    //// chunk if Transfer-Encoding of the response is 'chunked'.
+                    ////
+                    //// return !msg.isChunked();
                 }
                 break;
             case 'C':