PongWebSocketFrames are inaccessible in handlers downstream of a WebSocketClientProtocolHandler

This is probably more of a question / request rather than a bug, as it looks like this was a deliberate decision (source).

The use-case is a handler being able to assert that a pong frame was received from a Netty-based proxy server.

Expected behavior

PongWebSocketFrames are visible to a channel handler installed downstream of a WebSocketClientProtocolHandler.

Actual behavior

Sending a PingWebSocketFrame from a client to a server results in receipt of a PongWebSocketFrame by the client in the WebSocketClientProtocolHandler, but this frame is not propagated further along the channel pipeline.

Steps to reproduce

I’ve pushed a commit here which demonstrates the issue.

Minimal yet complete reproducer code (or URL to code)

Check out commit and run:

$ mvn test -pl codec-http -Dtest=io.netty.handler.codec.http.websocketx.PongFrameIgnoreTest

Netty version

4.1.25.Final. Also run against HEAD of 4.1 branch @ 987c44388.

JVM version (e.g. java -version)

$ java -version
java version "10.0.1" 2018-04-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode)

OS version (e.g. uname -a)

$ uname -a
Darwin nickt.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov  9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64

[nicktrav]

Yeah, that would be awesome for us. Principle of least surprise, etc, etc.

I might take a crack at this one, if that’s cool? I was thinking I’d just remove those lines so the frames are propagated, and I’ll add a couple tests for it in the server and client handler subclasses. Wdyt?

[normanmaurer]

@nicktrav actually I think the idea was that usually PONG frames should be dropped on the floor. That said I would argue that is not the best thing to do “magically” and it may be better to let the user decide to drop it or not. So maybe we should not do this ?