websocket icon indicating copy to clipboard operation
websocket copied to clipboard

Add the ability to define filters and interceptors

Open glassfishrobot opened this issue 12 years ago • 5 comments

In a future version of the WebSocket API, I would love to see the ability to specify filters and interceptors both on the client and server side. This could be very similar to how you can specify JAX-RS 2 filters and interceptors today (e.g. for encryption, compression, etc). Perhaps this could even be done via CDI interceptors somehow.

Do let me know if anything needs to be explained further - I am happy to help.

Please note that these are purely my personal views and certainly not of Oracle's as a company.

glassfishrobot avatar May 10 '13 21:05 glassfishrobot

  • Issue Imported From: https://github.com/javaee/websocket-spec/issues/199
  • Original Issue Raised By:@glassfishrobot
  • Original Issue Assigned To: @pavelbucek

glassfishrobot avatar Feb 12 '18 08:02 glassfishrobot

@glassfishrobot Commented Reported by reza_rahman

glassfishrobot avatar May 10 '13 21:05 glassfishrobot

@glassfishrobot Commented gdavison said: Specific use case:

"In section 4.3 of the JSR 356 spec there is an example of using a @PathParam to map part of the path to a parameter, but as per RFC 6455 4.2.2. it should be possible to return a 404 status code without initiating a WebSocket interchange.

I can't find an obvious code path to do this as presumable onOpen is too late as a message has already been send down the connection. Is there a -RS like request filter available so we can intercept this?'

glassfishrobot avatar May 13 '13 12:05 glassfishrobot

@glassfishrobot Commented This issue was imported from java.net JIRA WEBSOCKET_SPEC-199

glassfishrobot avatar Apr 24 '17 11:04 glassfishrobot

Filters and interceptors are essentially what extensions were designed for but there hasn't been as much take up of those as expected. See #340 for some further discussion on that.

The specific example of returning something other than a 101 response to the upgrade request is soemthign that can be considered for Jakarta EE 10. ServerEndpointConfig.Configurator#modifyHandshake() is the obvious place to do that. Need to figure out the best way to do that.

markt-asf avatar May 14 '20 20:05 markt-asf