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 (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) {
cause.printStackTrace();
ctx.close();
}
}
Run 1
The code is generally well-structured and readable, with clear intent. It follows a logical flow for handling HTTP responses and content, with minimal nesting and mostly one action per line. The method channelRead0 is concise, and the use of instanceof checks separates concerns effectively. However, there are minor readability issues: the nested loops for header iteration add slight complexity, and combining response and content handling in a single method could be more modular. The overall flow is natural, but the code assumes protocol ordering (response before content) without explicit handling. These factors slightly reduce readability from an excellent score, but the code remains clear and maintainable for experienced Netty developers.
Run 2
The code is generally readable with clear intent and logical organization. It uses flat nesting with only two levels, avoids unnecessary complexity, and has one action per line in most cases. The if-checks are straightforward and separated by blank lines for visual grouping. However, there is a slight readability issue: the loop printing headers is nested one level deeper than necessary and some logic (e.g., checking whether content is chunked) is embedded within a larger if-block without clear separation. Variable names are descriptive, and method names follow standard conventions. The code could be slightly more readable if HttpResponse and HttpContent handling were split into private methods, but overall it remains easy to follow.
Run 3
The code is relatively clear and logically organized, with separate handling for HttpResponse and HttpContent. Nesting is moderate—only a couple of levels deep in header iteration and conditional checks. Intent is evident: it logs HTTP response metadata and content. Variable names are meaningful. Action granularity is mostly one action per line, though the for-each loops could be split for clarity. Code length is appropriate—concise but not cramped. Reading flow is natural, following the order of HTTP response processing. Minor deductions: the multiple loops and repeated System.err.println calls slightly reduce conciseness, and comments or javadoc could improve clarity. Overall, it is readable code with only minor stylistic improvements possible.
Run 1
Code Structure: Logically separates response metadata, content handling, and exception handling. Nesting: Mostly shallow, though header printing reaches four nested control blocks and slightly slows scanning. Clarity of intent: Descriptive names and explicit output labels make the HTTP logging purpose clear; independent response and content checks appropriately support messages implementing both interfaces. Code length: Compact and proportionate to its purpose, with minor repetitive printing. Action granularity: Each statement performs one clear action, making execution easy to follow. Reading flow: Follows the natural sequence of status, headers, body, and completion, with whitespace separating stages. Minor drawbacks include inconsistent import ordering, tight spacing around loop colons, and header traversal embedded within the main handler.
Run 2
Code Structure: Logically organized into response metadata handling, content handling, and exception handling. Nesting: Mostly shallow, although header printing uses nested loops within two conditionals. Clarity of intent: Descriptive class, method, and variable names plus explicit output labels make the HTTP logging purpose clear. Code length: Concise for its functionality, with little unnecessary code. Action granularity: Each statement performs a single clear action on its own line. Reading flow: Processing naturally progresses from response status and headers to body content and connection closure; whitespace separates these stages effectively. Minor readability limitations include the comparatively deep header traversal and the lack of a brief explanation for the independent response and content checks.
Run 3
Code Structure: Well organized into message handling and exception handling, with distinct response and content sections. Nesting: Generally shallow, though the header traversal introduces several nested levels. Clarity of intent: Descriptive names, standard Netty types, and explicit output labels make the diagnostic purpose clear. Code length: Compact and appropriate for a small example handler; repeated printing is straightforward rather than unnecessarily verbose. Action granularity: Each statement performs a single clear action, with no compressed multi-action lines. Reading flow: Processing moves naturally from response metadata to headers, content, and connection closure. Minor limitations include slightly dense import formatting and nested header iteration, but overall the code is highly readable.