Jetty 在javax.websocket升级之前，如何使用过滤器

我想编写自己的“ServletContainerInitializer”，将本地筛选器添加到ServletContext。我还想管理ServletContainerInitializer调用的顺序，以便我的本地筛选器在websocket升级筛选器之前获得注册并被请求命中

---

我想知道如何初始化本地ServletContainerInitializer

首先，

ServletContextInitializer

未排序，该功能不是Servlet规范的一部分。您无法完成问题的这一部分。（可能在Servlet规范的未来版本中）

其次，不鼓励对WebSocket升级请求进行过滤，这也是WebSocket中出现大量问题的原因。您必须非常小心，不要执行以下任何操作

• 访问响应对象上的任何内容
• 不要包装请求或响应对象
• 不要访问请求输入流或读卡器
• 不要访问响应输出流或写入程序
• 不要添加标题
• 不要更改标题
• 不访问请求HttpSession
• 不访问请求用户主体
• 不访问请求身份验证/授权方法
• 不访问请求部分（多部分/表单数据）
• 不访问请求参数
• 不访问ServletContext
• 不访问request.getScheme或isSecure
• 不要从请求中删除内容（属性、标题、参数等）

简而言之，你能做的唯一安全的事情就是

• request.getAttribute（字符串名称）
• request.getContextPath（）
• request.getCookies（）
• request.getHeader（字符串名称）
• request.getIntHeader（字符串名称）
• request.getLocalName（）
• request.getLocalPort（）
• request.getPathInfo（）
• request.getPathTranslated（）
• request.getQueryString（）
• request.getRemoteAddr（）
• request.getRemotePort（）
• request.getRequestURI（）
• request.getRequestURL（）
• request.getServerName（）
• request.getServerPort（）

因为对请求或响应对象的所有其他访问将更改请求的状态并阻止升级

Jetty具有WebSocketUpgradeFilter这一事实正是我们在实现JSR-356（又名javax.websocket）规范时的选择。它是由服务器端

ServletContextInitializer

和添加的

实际上，您应该在Servlet处理（包括过滤器）之前进行升级，因为规范就是这样编写的。有，但这些问题目前尚未得到解答，并且计划在javax.websocket规范的未来版本中发布

Jetty的未来版本可能会从使用过滤器变为使用在路径映射级别进行协作的内部工具，将Servlet规范和WebSocket规范中的逻辑合并为一组新的规则

由于这个问题经常出现，我已经勾选了社区维基标志

问这个问题的第一个原因是，在项目的过滤器中内置了一些身份验证或授权逻辑

如果是这种情况，您有两种选择

将身份验证和/或授权逻辑重构为独立类，与过滤器无关

构建一个新的

过滤器

和一个新的过滤器，该过滤器使用现在通用的逻辑来完成您需要的最终结果。请注意，在可能的WebSocket升级下，您无权访问整个

HttpServletRequest

对象，只能访问对象内容。（您现在可以看到限制）

正确使用Servlet规范和容器，并在容器级别实现/配置安全性，这将始终在websocket、Servlet或过滤器之前执行。因此，完全删除基于安全性的过滤器