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 channel(ChannelHandlerContext ctx, HttpObject msg) {
if (msg instanceof HttpResponse) {
HttpResponse res = (HttpResponse) msg;
System.err.println("STATUS: " + res.status());
System.err.println("VERSION: " + res.protocolVersion());
System.err.println();
if (!res.headers().isEmpty()) {
for (CharSequence nam: res.headers().names()) {
for (CharSequence val: res.headers().getAll(nam)) {
System.err.println("HEADER: " + nam + " = " + val);
}
}
System.err.println();
}
if (HttpUtil.isTransferEncodingChunked(res)) {
System.err.println("CHUNKED CONTENT {");
} else {
System.err.println("CONTENT {");
}
}
if (msg instanceof HttpContent) {
HttpContent con = (HttpContent) msg;
System.err.print(con.content().toString(CharsetUtil.UTF_8));
System.err.flush();
if (con instanceof LastHttpContent) {
System.err.println("} END OF CONTENT");
ctx.close();
}
}
}
@Override
public void exception(ChannelHandlerContext ctx, Throwable cau) {
cau.printStackTrace();
ctx.close();
}
}
Run 1
The code is generally readable with a logical structure: it separates response header handling from content handling, uses clear variable names like 'res' and 'con', and maintains flat nesting with only two levels of indentation. Action granularity is good—each print statement is on its own line. However, there are notable issues: missing @Override annotations on handler methods, slightly ambiguous method names ('channel' and 'exception' lack the 'Read'/'Caught' suffix typical of Netty handlers), and redundant explicit type casts that add noise. The code is concise but could be more intentional about naming conventions. Overall, it's approachable for developers familiar with Netty but lacks polish in clarity of intent.
Run 2
The code follows a clear structure with two main conditional blocks handling different HTTP message types. However, it has several readability issues: the method name 'channel' is not descriptive, and 'nam'/'cau' are ambiguous abbreviations. The nested loop for headers adds complexity, and multiple operations are packed into single lines (print + flush). While the flow is generally logical and flat, the intent could be clearer. The code would benefit from better method naming, extracting header printing logic, and adding a newline after header output. The use of System.err for normal output is also misleading. Overall, it's understandable but not particularly polished in terms of clarity and naming conventions.
Run 3
The code has reasonable structure with a clear class purpose and logical separation of concerns. However, readability is hindered by several issues: the `@Override` annotation is missing on the `channel` method (it should be `channelRead0` for Netty 4), and variable names are unnecessarily abbreviated (`res`, `con`, `nam`, `val`, `cau`), reducing clarity. The nested loops for headers add depth but remain manageable. The if-else blocks for chunked vs regular content are flat and clear. Each line performs one action, which is good, but the `System.err.println()` calls could be consolidated. The code is concise and follows a natural flow, but the missing annotation and abbreviated names make the intent slightly ambiguous. Overall, it's readable but could be improved with better naming and proper method annotations.
Run 1
Code Structure: Response metadata, content processing, and exception handling are logically separated. Nesting: Mostly shallow, although header printing reaches four nested control levels. Clarity of intent: HTTP response logging is obvious from the output labels and type checks; abbreviated names such as nam, con, and cau slightly weaken clarity. The unconventional callback names channel and exception may confuse readers familiar with Netty. Code length: Compact and generally appropriate, with minor repetition in printing statements. Action granularity: Each statement performs a single clear action on its own line. Reading flow: Processing naturally moves from status and headers to body content and completion, followed by error handling. Consistent indentation and blank lines aid scanning, though import organization and spacing around enhanced-for colons could be improved.
Run 2
Code Structure: Response metadata, content handling, and exception handling are logically separated. Nesting: Most logic is shallow, but header printing reaches four nested levels. Clarity of intent: Output labels make the diagnostic purpose clear; abbreviated variables (res, nam, val, con, cau) and unconventional callback names reduce clarity. Code length: Compact and appropriate, with little unnecessary code. Action granularity: Each statement performs one action, making execution easy to follow. Reading flow: Processing moves naturally from response metadata to content and cleanup, with useful blank lines. However, inconsistent spacing and potentially incorrect Netty override names (channel and exception) may confuse readers familiar with the framework.
Run 3
Code Structure: Logically separates response metadata, content processing, and exception handling. Nesting: Mostly shallow, but header printing reaches four nested levels, slightly slowing comprehension. Clarity of intent: Output labels and familiar Netty types make the purpose clear; abbreviated names such as res, con, nam, val, and cau, plus vague method names channel and exception, reduce clarity. Code length: Compact and appropriate for a simple logging handler, with little unnecessary code. Action granularity: Each statement performs one clear action, with no compressed multi-statement lines. Reading flow: Processing follows a natural metadata-to-content sequence, and whitespace separates related operations. Minor formatting inconsistencies and nonstandard callback names detract from otherwise readable code.