Ordering of filters, servlets in Jetty-9.2.2

问题

I am deploying CometD-3.0.1 in jetty-9.2.2.

I have my own filters which I want to call for every request. I have specified those filters in the web.xml in particular order.

But with WebSocket, containers have to find a way to handle the upgrade request. In Jetty, this is done by a servlet filter that is always added as first filter by a ServletContainerInitializer. So in my case, a upgrade request will never hit my filter, because the WS filter that's in the front of the chain will do the upgrade before hitting my filter.

What should I do so that my filters will be invoked first before the WS filters of Jetty ?

Thanks, Anuj

回答1:

In short, it is impossible to run a servlet filter on a websocket upgrade.

The choice in jetty to have WebSocket upgrade handled by a filter is just our particular implementation of the Servlet and WebSocket specs. Other implementations might use different techniques.

Theres 2 things to understand about this.

1. If the container had configured WebSocket endpoints on known path mappings / path specs, then any upgrade request that arrives is handled BEFORE all servlet processing. Jetty chose to do this via an internal filter, other implementations do this with special processing before handling it off to the servlet chain.

2. Servlet Filtering of websocket upgrades was discouraged early on in the servlet spec as most any changes a filter can do will cause problems to a websocket upgrade. There was brief talk about rejecting some code paths that were known to cause problems (like accessing the request content or response content, setting headers in the request or response, etc..) But this proved to be too invasive, so it was declared to be not possible and discouraged.

Now, you should know that if the websocket upgrade doesn't occur, and without an error, then the servlet processing chain does kick in for that request.

A typical problem here is that some folks have built their security around filters, this is good for Servlets, but not WebSockets.

If this is the case, then you have some work ahead of you.

Pick of of the following:

• Split out the security logic into a standalone class that your Servlet Filters and your custom javax.websocket.server.ServerEndpointConfig.Configurator can use.

or

• Implement your security using the security layers of the container (that always happen before any processing of websockets or servlets)

来源：https://stackoverflow.com/questions/25741365/ordering-of-filters-servlets-in-jetty-9-2-2