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 well-structured with clear separation of concerns and logical organization. It handles HTTP responses and content in flat, easily readable blocks with minimal nesting. Intent is clear from descriptive method and variable names. The code is concise and avoids unnecessary length. Each line generally performs one action, contributing to readability. The reading flow is natural, following the HTTP message processing sequence. Minor improvements could include extracting repeated System.err.println calls or using string formatting, but overall the code is highly readable for a Netty handler implementation.
Run 2
The code is generally readable: it has a clear class purpose, straightforward sequential logic, and reasonable method decomposition. The main method 'channelRead0' is relatively flat with only one level of conditional nesting plus inner loops for headers. Variable names are descriptive, and each action is mostly on its own line. However, readability is slightly reduced by minor issues: the method name 'channelRead0' is less intuitive than an override like 'messageReceived', and the two main if blocks could be separated by a blank line or helper methods to improve flow. The header iteration is slightly verbose, and mixing status/header printing with content handling in one method makes the logic somewhat dense. Overall, the code is approachable and maintainable, but would benefit from modest structural refinement.
Run 3
The code is well-structured and readable overall. It has clear separation of concerns (HTTP response vs content handling), minimal nesting, and concise method implementations. The intent is obvious: log HTTP response details and content. Action granularity is appropriate, with logical operations grouped separately. However, there are some structural inconsistencies: opening brace placement for the CHUNKED/CONTENT block is asymmetric, and the blank line between the two if-statements is missing, slightly disrupting flow. The code could be improved by extracting header-printing logic into a private method to enhance clarity. Overall, it's straightforward but has minor style issues.
Run 1
Code Structure: Clearly separates response metadata, content handling, and exception handling. Nesting: Mostly shallow, although 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 obvious; independent response and content checks correctly allow a message to satisfy both types. Code length: Compact for its functionality, with only minor repetitive printing. Action granularity: Each statement performs a single clear action on its own line. Reading flow: Follows a natural progression from status and headers to content and connection closure. Blank lines improve grouping, though separating header printing into a helper and adding spacing after the package declaration would improve readability.
Run 2
Code Structure: Clearly separates response metadata, content handling, and exception handling. Nesting: Mostly shallow, though header printing uses three nested control structures. Clarity of intent: Descriptive class, method, and variable names, plus explicit output labels, make the HTTP snooping purpose clear. Code length: Compact and appropriate for its functionality, with little unnecessary repetition. Action granularity: Each statement performs one primary action; printing, flushing, and closing are separate. Reading flow: Processing moves naturally from status and headers to content and completion, with consistent indentation and helpful blank lines. Minor readability drawbacks include the nested header loops and the lack of an explanation for why response and content checks are independent.
Run 3
Code Structure: Logically separates response metadata, content processing, and exception handling. Nesting: Mostly shallow, though header printing uses nested loops inside two conditionals. Clarity of intent: Descriptive names, standard Netty types, and explicit output labels make its diagnostic purpose clear. Code length: Compact and appropriate for a small example handler, with little unnecessary code. Action granularity: Each statement performs a distinct action on its own line. Reading flow: Processing proceeds naturally from status and headers to content and completion; exception handling is clearly isolated. Minor readability drawbacks include repeated output calls, slightly inconsistent spacing, and the relatively deep header traversal.