此URL不支持WildFly:HTTP方法POST

Question

我正在开发一个运行在WildFly 18和Angular前端的Java EE web应用程序。从Angular到Wildfly的所有HTTP调用都是POST。该应用程序运行良好，但每月启动一次时，我无法使用它，因为Wildfly拒绝了请求，称HTTP method POST is not supported by this URL(请参阅浏览器控制台上的错误)。为了确保不是Angular，我从一个Java程序中进行了POST调用，得到了同样的错误。

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

visualcode/rest/getbropr:1无法加载资源：服务器响应的状态为405(方法不允许)main.js:1127HttpErrorResponse错误："错误HTTP方法POST不是由该URL支持"；headers:HttpHeaders｛normalizedNames:Map(0)，lazyUpdate:null，lazyInit:ƒ｝消息："的Http失败响应http://localhost:4400/visualcode/rest/getbropr:405方法不是允许的"；名称："；HttpErrorResponse"；ok：false状态：405状态文本："方法不允许"；网址："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

目前我在他的问题跟踪器中没有发现任何类似的问题。我也没有遇到过类似的问题，野蝇17和19。

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

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

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

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

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

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

更新：

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

<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

script.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

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

另一方面，你测试过Wildfly 20中的问题是否仍然存在吗？在18-20之间更新野生蝇相对简单。

更新2:

请求看起来不错，所以我建议您查看启动日志。开始时似乎是一种比赛条件，Wildfly同时运行许多任务以尽快开始。

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

希望我能帮助