andreacavalli/netty5
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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

Browse Source 
* 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.
This commit is contained in:
Trustin Lee 2011-08-02 08:34:56 +09:00
parent bdeed00bbb
commit 5c62d54c67
1 changed files with 14 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -136,11 +136,20 @@ public class HttpClientCodec implements ChannelUpstreamHandler,
// 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':