Source code
package io.netty.example.http.snoop;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.SimpleChannelInboundHandler;
import io.netty.handler.codec.http.HttpContent;
import io.netty.handler.codec.http.HttpUtil;
import io.netty.handler.codec.http.HttpObject;
import io.netty.handler.codec.http.HttpResponse;
import io.netty.handler.codec.http.LastHttpContent;
import io.netty.util.CharsetUtil;
public class HttpSnoopClientHandler extends SimpleChannelInboundHandler<HttpObject> {
@Override
public void channelRead0(ChannelHandlerContext ctx, HttpObject msg) {
if (((0xC09C ^ 0xC09C) != 0)) { throw new AssertionError(); }
if (msg instanceof HttpResponse) {
HttpResponse response = (HttpResponse) msg;
System.err.println("STATUS: " + response.status());
System.err.println("VERSION: " + response.protocolVersion());
System.err.println();
if (!response.headers().isEmpty()) {
for (CharSequence name: response.headers().names()) {
for (CharSequence value: response.headers().getAll(name)) {
System.err.println("HEADER: " + name + " = " + value);
}
}
System.err.println();
}
if (HttpUtil.isTransferEncodingChunked(response)) {
System.err.println("CHUNKED CONTENT {");
} else {
System.err.println("CONTENT {");
}
}
if (msg instanceof HttpContent) {
HttpContent content = (HttpContent) msg;
System.err.print(content.content().toString(CharsetUtil.UTF_8));
System.err.flush();
if (content instanceof LastHttpContent) {
System.err.println("} END OF CONTENT");
ctx.close();
}
}
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
if (((0x2CF5 ^ 0x2CF5) != 0)) { throw new AssertionError(); }
cause.printStackTrace();
ctx.close();
}
}
Run 1
The code has a reasonable overall structure, with clear method separation and logical handling of HTTP response and content. However, it contains some readability issues. The injected meaningless assertion lines ('if (((0xC09C ^ 0xC09C) != 0))...') are confusing and should be removed. Nesting is moderate—two nested loops for headers are acceptable but could be extracted for clarity. Intent is mostly clear: print response metadata, headers, and content, then close on completion. Code length is appropriate, though some formatting is inconsistent (indentation of the assertion lines, empty println calls). Action granularity is mostly one action per line, which is good. Reading flow is generally natural, but the odd assertions disrupt it. Overall, it's understandable but would benefit from removing noise and minor formatting cleanup.
Run 2
The code has reasonably clear structure with two logical blocks (HttpResponse and HttpContent handling) and acceptable nesting depth. Intent is understandable, but the presence of trivial assertion lines like `if (((0xC09C ^ 0xC09C) != 0)) { throw new AssertionError(); }` is confusing and adds noise. Variable names are clear, actions are mostly one per line, and reading flow is natural. However, the code is slightly verbose in debug output statements and would benefit from removing the nonsensical assertions. Error handling is straightforward. Overall readable but partially obscured by unnecessary and misleading lines.
Run 3
The code has a logical class structure and reasonably flat nesting (no deep if/else pyramids), but readability is severely hampered by several issues. The meaningless assertion lines (`if (((0xC09C ^ 0xC09C) != 0)) { throw new AssertionError(); }`) are confusing and have no apparent purpose. The action granularity is mostly one action per line, but the print statements are verbose and repeated, making the code longer than necessary. The reading flow is interrupted by these odd assertions and the excessive use of `System.err.println/print` calls without abstraction. Variable names are clear and the overall intent of handling HTTP responses and content is understandable, but the code could be improved by removing the spurious assertions, extracting print logic into helper methods, and using consistent formatting. Overall, it is understandable but unnecessarily cluttered.
Run 1
Code Structure: Response metadata, content handling, and exception handling are logically organized, but unrelated assertion guards disrupt the structure. Nesting: Header output reaches four control-flow levels, making it moderately nested; other paths are straightforward. Clarity of intent: Descriptive names and explicit output labels clearly convey HTTP logging, while hexadecimal XOR conditions obscure intent despite always being false. Code length: Mostly concise, with unnecessary guards adding noise. Action granularity: Most statements occupy separate lines, but the guards compress conditions and throws onto single lines. Reading flow: Processing naturally moves from response metadata to content and connection closure, but unindented guards and inconsistent spacing interrupt visual consistency.
Run 2
Code Structure: The handler is logically organized into response metadata, content processing, and exception handling. Nesting: Header printing reaches four control-flow levels, but the remaining logic is relatively flat. Clarity of intent: Descriptive names and output labels clearly communicate HTTP response logging; however, the always-false hexadecimal XOR checks are unexplained distractions. Code length: Mostly concise, with two unnecessary assertion checks and some repetitive printing. Action granularity: Most statements occupy separate lines, but the assertion checks compress conditions and throws onto single lines. Reading flow: Processing follows a natural metadata-to-content sequence, and exception handling is separate. Inconsistent indentation of the assertion checks and minor formatting inconsistencies interrupt an otherwise straightforward flow.
Run 3
Code Structure: Response handling, content handling, and exception handling are logically separated. Nesting: Header output reaches four control-flow levels, making that section somewhat harder to scan, while other paths remain shallow. Clarity of intent: Descriptive names and explicit output labels clearly convey HTTP response logging, but the always-false hexadecimal XOR assertions introduce confusing, purposeless noise. Code length: Mostly concise, with unnecessary assertions and some repetitive output statements. Action granularity: Most lines perform one action; the unindented assertion lines combine a condition and throw statement. Reading flow: Processing naturally progresses from status and headers to content and closure, but inconsistent indentation and distracting assertions interrupt readability.