净额，字符串和冲洗

Question

I'm experimenting with adapting the example Netty proxy, to make it modify some of the content en-route.

I'm proxying between an FTP client and server, so lines end in CRLF -- that's important. I'm not yet doing anything with FTP data ports, so that is not a factor.

I started with this example code: https://netty.io/4.0/xref/io/netty/example/proxy/package-summary.html

... which sets up a pipeline like this:

ch.pipeline().addLast(
      new LoggingHandler(LogLevel.INFO),
      new HexDumpProxyFrontendHandler(remoteHost, remotePort));

... and that works fine.

If I add a new LineBasedFrameDecoder(maxLen) the ftp client hangs waiting for the server, because the proxy has stripped off CRLF, and the server is still waiting. I can fix this by telling the frame decoder not to remove the delimiters: new LineBasedFrameDecoder(maxLen, false, false) .

ch.pipeline().addLast(
      new LoggingHandler(LogLevel.INFO),
      new LineBasedFrameDecoder(maxLen, false, false),
      new HexDumpProxyFrontendHandler(remoteHost, remotePort));

So far, so good. But if I add a String decoder, I get the same hanging symptom, this time because the pipeline step after StringDecoder is not invoked.

ch.pipeline().addLast(
      new LoggingHandler(LogLevel.INFO),
      new LineBasedFrameDecoder(maxLen, false, false),
      new StringDecoder(StandardCharsets.UTF_8),
      // aim is for my own string rewriter to go here
      new StringEncoder(StandardCharsets.UTF_8),
      new HexDumpProxyFrontendHandler(remoteHost, remotePort));

In a debugger, a breakpoint in StringEncoder.encode() does not trigger.

How can I tell Netty to process the String after decoding?

Answer 1

StringEncoder is an outbound channel adapter. It's purpose is to convert from String to ByteBuf when writing, so I would not expect encode to be called on inbound data.

In order for your code to work, you would need to replace StringEncoder with an inbound channel adapter that converts from String to ByteBuf when reading. I doubt that any such codec exists in the Netty library because decoders generally convert from a lower level format to a higher level format, not the other way around.

Since LineBasedFrameDecoder emits ByteBuf's and HexDumpProxyFrontendHandler consumes ByteBufs I would recommend that you remove both StringDecoder and StringEncoder and insert your customer rewriter. But .. make it a ByteBuf to ByteBuf decoder. Within your decoder you can convert the incoming ByteBuf to a String, do your work, then convert it back to ByteBuf then pass it down the pipeline.