WildFly：此 URL 不支持 HTTP 方法 POST

Question

我正在开发在 WildFly 18 上运行的 Java EE web 应用程序，并在前端开发 Angular。 从 Angular 到 Wildfly 的所有 HTTP 调用都是 POST。 该应用程序工作正常，但是每月一次，当我启动它时，我无法使用它，因为 Wildfly 拒绝了该请求，说此HTTP method POST is not supported by this URL （请参阅下面的浏览器控制台上的错误）。 只是为了确保不是 Angular，我从 Java 程序进行了 POST 调用，得到了同样的错误。

解决方案是关闭所有内容并重新启动，有时不止一次。 为什么会发生这种情况以及如何解决这个问题？ 最大的问题是这可能在生产中发生。

visualcode/rest/getbropr:1 加载资源失败：服务器响应状态为 405（不允许使用方法） main.js:1127 HttpErrorResponse 错误：“此 URL 不支持错误 HTTP 方法 POST”标题：HttpHeaders {normalizedNames ：映射（0），lazyUpdate：null，lazyInit：ƒ} 消息：“http://localhost:4400/visualcode/rest/getbropr 的 Http 失败响应：405 方法不允许”名称：“HttpErrorResponse”ok：false 状态： 405 statusText：“方法不允许”url：“http://localhost:4400/visualcode/rest/getbropr”

更新

这发生在两台具有相同 Wildfly 配置的不同机器上，因此它必须与 JAX-RS 或任何其他相关组件的设置方式有关。

更新 2

我收到了错误，这是服务器日志：

11:46:17,306 DEBUG [io.undertow.request] (default I/O-12) Matched prefix path /visualcode for path /visualcode/rest/getbropr
11:46:17,306 DEBUG [io.undertow.request.security] (default task-1) Attempting to authenticate /visualcode/rest/getbropr, authentication required: false
11:46:17,306 DEBUG [io.undertow.request.security] (default task-1) Authentication outcome was NOT_ATTEMPTED with method io.undertow.security.impl.CachedAuthenticatedSessionMechanism@2d8f2c0a for /visualcode/rest/getbropr
11:46:17,306 DEBUG [io.undertow.request.security] (default task-1) Authentication result was ATTEMPTED for /visualcode/rest/getbropr
11:46:17,307 INFO  [io.undertow.request.dump] (default task-1) 
----------------------------REQUEST---------------------------
               URI=/visualcode/rest/getbropr
 characterEncoding=null
     contentLength=2
       contentType=[application/json]
            cookie=_ga=GA1.1.1378850711.1587329434
            header=accept=application/json, text/plain, */*
            header=accept-language=en-US,en;q=0.9,es;q=0.8
            header=accept-encoding=gzip, deflate, br
            header=sec-fetch-mode=cors
            header=origin=http://localhost:4400
            header=user-agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36
            header=sec-fetch-dest=empty
            header=connection=close
            header=sec-fetch-site=same-origin
            header=cookie=_ga=GA1.1.1378850711.1587329434
            header=content-type=application/json
            header=content-length=2
            header=referer=http://localhost:4400/login
            header=host=localhost:8080
            locale=[en_US, en, es]
            method=POST
          protocol=HTTP/1.1
       queryString=
        remoteAddr=/127.0.0.1:51323
        remoteHost=kubernetes.docker.internal
            scheme=http
              host=localhost:8080
        serverPort=8080
          isSecure=false
--------------------------RESPONSE--------------------------
     contentLength=104
       contentType=text/html;charset=UTF-8
            header=Connection=close
            header=Content-Type=text/html;charset=UTF-8
            header=Content-Length=104
            header=Date=Thu, 09 Jul 2020 15:46:17 GMT
            status=405

==============================================================

这是（有时）失败的代码：

@Path("/")
@Consumes({ MediaType.APPLICATION_JSON })
@Produces({ MediaType.APPLICATION_JSON })
public class LoginService {
    
    @Inject
    private SomeBean bean;
    
    @Context
    private HttpServletRequest httpRequest;

    @POST
    @Path("/getbropr")
    public Response getBrowserProperties() {
          // process response
    }

Answer 1

目前我在他的问题跟踪器中没有发现任何类似的问题。 Wildfly 17 和 19 也没有类似的问题。

因此，我建议您检查以解决问题的第一件事是进行以下检查并收集某些信息以提供帮助：

1. 首先检查 wildfly 日志并在跟踪或调试模式下更改它们
2. 其次，验证您没有通过平衡器、反向代理、防火墙或任何可能是您在客户端看到的响应的发布者的中介
3. 记录所进行的调用，包括（url、标头、http 方法、参数和正文）以及收到的答案的相同数据，或者尝试使用 postman 等可视化工具或通过命令行使用类似命令来重现调用curl。

通过这些测试，您可以首先确定服务响应的真实来源。 有时平衡器、网络等中的错误配置可能会导致呼叫未到达目的地，而应答的是另一项服务。

检查包含的标头很有用，因为有时会找到跟踪。 或者响应正文中的格式或消息，这可以是确定来源的另一种指示。

如果我们已经确认起源是服务，那么我们可以方便的回顾从它开始失败的那一刻起的痕迹。 当内部发生故障时，可能会有故障或处理不当的异常的线索。 例如，如果我们将 Resteasy (jax-rs) 与 wildfly 一起使用（这很常见），当出现内部错误（数据库不可用、内部服务无法访问等）或异常映射器错误时会抛出异常。 .. 它可能会导致打印不正确的消息和错误代码，这会分散解决实际问题的注意力（这种情况不会很常见，但请记住这一点，查看日志会有所帮助）。

如果在分析响应，确认其来源，分析跟踪和异常之后，您的问题仍然存在...我建议您在此线程中提供您的应用程序的更多详细信息（例如，java 版本，libs，直接使用 servlet 或 resteasy 实现？ ，身份验证？等）...您可以提供的任何信息，例如可用于重现问题的跟踪或具有相似特征的小演示，都将受到欢迎，以帮助您解决问题。

更新：

知道您在本地运行服务，我要求您配置 Wildfly 以在日志中打印调用及其参数。 Wildfly 使用 undertow 作为引擎，因此请在您的 undertow 配置中添加一个过滤器以记录您的请求。 添加到您的standalone.xml -> 子系统“undertow”以下配置：

<subsystem xmlns = "urn:jboss:domain: undertow: 3.0">
         <server name = "default-server">
             <host name = "default-host" alias = "localhost">
...
                 <filter-ref name = "request-logger" />
             </host>
         </server>
         <filters>
...
             <filter name = "request-logger" module = "io.undertow.core"
               class-name = "io.undertow.server.handlers.RequestDumpingHandler" />
         </filters>
     </subsystem>

或者，您可以使用以下脚本使用 jboss-cli.sh 更改 xml 配置：

$WILDFLY_HOME/bin/jboss-cli.sh --connect --file=script.cli

脚本.cli 文件：

batch
/subsystem=undertow/configuration=filter/custom-filter=request-logging-filter:add(class-name=io.undertow.server.handlers.RequestDumpingHandler, module=io.undertow.core)
/subsystem=undertow/server=default-server/host=default-host/filter-ref=request-logging-filter:add
run-batch

通过开放端口到达undertow 的任何呼叫都应记录在您的日志中收到的数据，这将有助于了解呼叫是否到达wildfly 并能够追踪问题。 如果调用实际到达wildfly，稍后也欢迎调试日志。

另一方面，您是否测试过 Wildfly 20 中是否仍然存在问题？ 在 18-20 之间更新 wildfly 相对简单。

更新 2：

该请求看起来不错，因此我建议您检查启动日志。 似乎是开始时的竞争条件，Wildfly 同时运行许多任务以尽快开始。

通常，当您在类路径或启动代码中有重复的配置文件时，可能会导致意外行为，因此比较日志很有帮助。 检查您的.war 文件中是否只有 web.xml 和文件描述符。

希望我能帮上忙