On Big Endian platforms, the FullHttpRequest object always has a zero length content because of inconsistent hash values in CASE_INSENSITIVE_HASHER

[ekuehnhausen]

Netty version: netty-all-4.1.5.Final.jar

On Big Endian platforms, the FullHttpRequest object always has a zero length content. I've been able to trace this in the debugger to the CASE_INSENSITIVE_HASHER in io.netty.util.AsciiString.java not returning consistent hashes for the "content-length" field on Big Endian platforms.

Some background: I'm using Netty to process REST requests from clients.
As part of the channel initializer, I'm adding a new HttpServerCodec() to the channel pipeline.
ch.pipeline.addLast(new HttpServerCodec());

What I've noticed is that on Big Endian platforms (specifically, Solaris sparc 5.10 and HP-UX-IA64 B.11.31), the Content-Length header is not being stored and retrieved consistently. This has the effect that Netty never reads the content from the HTTP request from the client.

Using the debugger, I've been able to track this down to inconsistent hash values in the CASE_INSENSITIVE_HASHER in io.netty.util.AsciiString on Big Endian machines (this issue does not appear on Little Endian machines).

When reading the headers from the HTTP client request --
HttpRequestDecoder(HttpObjectDecoder).readHeaders(ByteBuf) line: 584 --
the header gets added as "Content-Length" (mixed case). The hash value computed for this in the DeafultHeaders.add function is 2100908492.

Later, when this Content-Length header is retrieved by HttpUtil.getContentLength(HttpMessage, long) line: 185, it is looked up in all lower case as "content-length" and the hash value computed in DefaultHeaders.get is 193356951.

Since the hash value used on the "get" doesn't match what was used on the "add", the content-length value is not found. This results in the Netty failing to read the content from the socket and a FullHttpRequest object with 0 length content passed to my channel handler.

[rz-itac]

Hi!
I think this is related to: #5916
Please check my comment: #5916 (comment)

[normanmaurer]

@Scottmitch PTAL

[Scottmitch]

@rz-itac - thanks for reporting. I'm not surprised there is a bug here as I was not able to get my hands on a big endian machine, and emulating a big endian machine was very painful IIRC. Let me take a deeper look.

Just to confirm our unit tests would have picked up this failure if run on a big endian machine can you run the following and let me know if you get test failures on your Solaris machine (assuming you have java 7, git, and maven 3.1.1+ installed)

git clone git@github.com:netty/netty.git
cd netty/common
mvn test

[Scottmitch]

@rz-itac - Please verify PR #5935