简体   繁体   English

WildFly:此 URL 不支持 HTTP 方法 POST

[英]WildFly: HTTP method POST is not supported by this URL

I'm developing a Java EE web application running on WildFly 18, and Angular on the front end.我正在开发在 WildFly 18 上运行的 Java EE web 应用程序,并在前端开发 Angular。 All the HTTP calls from Angular to Wildfly are POSTs.从 Angular 到 Wildfly 的所有 HTTP 调用都是 POST。 The application works fine, but once a month, when I start it, I cannot use it because Wildfly rejects the request saying that the HTTP method POST is not supported by this URL (see error below on browser console).该应用程序工作正常,但是每月一次,当我启动它时,我无法使用它,因为 Wildfly 拒绝了该请求,说此HTTP method POST is not supported by this URL (请参阅下面的浏览器控制台上的错误)。 Just to make sure is not Angular, I made the POST call from a Java program, and got the same error.只是为了确保不是 Angular,我从 Java 程序进行了 POST 调用,得到了同样的错误。

The solution is to close everything and restart, sometimes more than once.解决方案是关闭所有内容并重新启动,有时不止一次。 Why does this happen and how to fix this?为什么会发生这种情况以及如何解决这个问题? The big problem is that this may happen in production.最大的问题是这可能在生产中发生。

visualcode/rest/getbropr:1 Failed to load resource: the server responded with a status of 405 (Method Not Allowed) main.js:1127 HttpErrorResponse error: "Error HTTP method POST is not supported by this URL" headers: HttpHeaders {normalizedNames: Map(0), lazyUpdate: null, lazyInit: ƒ} message: "Http failure response for http://localhost:4400/visualcode/rest/getbropr: 405 Method Not Allowed" name: "HttpErrorResponse" ok: false status: 405 statusText: "Method Not Allowed" url: "http://localhost:4400/visualcode/rest/getbropr" 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”

UPDATE更新

This happened to me in two different machines with identical Wildfly configuration, so it must be something on how JAX-RS or any other related component is set up.这发生在两台具有相同 Wildfly 配置的不同机器上,因此它必须与 JAX-RS 或任何其他相关组件的设置方式有关。

UPDATE 2更新 2

I got the error and this is the server log:我收到了错误,这是服务器日志:

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

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

And this is the code that (sometimes) fails:这是(有时)失败的代码:

@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
    }

At the moment I did not find any similar issue in his issue tracker.目前我在他的问题跟踪器中没有发现任何类似的问题。 I have also not had a similar problem with wildfly 17 and 19. Wildfly 17 和 19 也没有类似的问题。

So, the first Thing I suggest you check to solve the problem is to carry out the following checks and collect certain information to help:因此,我建议您检查以解决问题的第一件事是进行以下检查并收集某些信息以提供帮助:

  1. first check the wildfly logs and change them in trace or debug mode首先检查 wildfly 日志并在跟踪或调试模式下更改它们
  2. Second verify that you are not going through a balancer, reverse proxy, firewall or any intermediary that may be the issuer of the response that you are seeing in the client其次,验证您没有通过平衡器、反向代理、防火墙或任何可能是您在客户端看到的响应的发布者的中介
  3. Log the call made including (url, headers, http method, parameters and body) and the same data of the received answer, or try if it is possible to reproduce the call with a visual tool like postman or by command line with a command like curl.记录所进行的调用,包括(url、标头、http 方法、参数和正文)以及收到的答案的相同数据,或者尝试使用 postman 等可视化工具或通过命令行使用类似命令来重现调用curl。

With these tests, you can first determine the true origin of the service response.通过这些测试,您可以首先确定服务响应的真实来源。 sometimes bad configurations in balancers, networks, etc. can cause that the calls do not arrive at the destination and the one that answers is another service.有时平衡器、网络等中的错误配置可能会导致呼叫未到达目的地,而应答的是另一项服务。

It is useful to check the headers that are included, since traces are sometimes found.检查包含的标头很有用,因为有时会找到跟踪。 Or the format or message in the body of the response, which can be another indication to determine the origin.或者响应正文中的格式或消息,这可以是确定来源的另一种指示。

If we have confirmed that the origin is the service, it is convenient for us to review the traces from the moment it began to fail backwards.如果我们已经确认起源是服务,那么我们可以方便的回顾从它开始失败的那一刻起的痕迹。 There may be clues to a fault or a mishandled exception when a fault occurs internally.当内部发生故障时,可能会有故障或处理不当的异常的线索。 For example if we are using Resteasy (jax-rs) with wildfly (which is quite common), an exception thrown wrong when there is an internal error (database not available, internal services unreachable, etc.) or an exception mapper is wrong... it can cause an incorrect message and error code to be printed which would be a distraction to solve the real problem (it would not be something very common that happens but it is a point to keep in mind and reviewing the logs can help here).例如,如果我们将 Resteasy (jax-rs) 与 wildfly 一起使用(这很常见),当出现内部错误(数据库不可用、内部服务无法访问等)或异常映射器错误时会抛出异常。 .. 它可能会导致打印不正确的消息和错误代码,这会分散解决实际问题的注意力(这种情况不会很常见,但请记住这一点,查看日志会有所帮助)。

if after analyzing the response, confirming its origin, analyzing the traces and exceptions, your problem persists... I suggest you provide greater detail of your application in this thread (for example, java version, libs, implement direct with servlet or resteasy?, authentication?, etc)... any information you can provide such as the trace or a small demo with similar characteristics that can be used to reproduce the problem will be welcome to help you solve the problem.如果在分析响应,确认其来源,分析跟踪和异常之后,您的问题仍然存在...我建议您在此线程中提供您的应用程序的更多详细信息(例如,java 版本,libs,直接使用 servlet 或 resteasy 实现? ,身份验证?等)...您可以提供的任何信息,例如可用于重现问题的跟踪或具有相似特征的小演示,都将受到欢迎,以帮助您解决问题。

Update:更新:

Knowing that you are running the service locally, I ask you to configure Wildfly to print the call and its parameters in your logs.知道您在本地运行服务,我要求您配置 Wildfly 以在日志中打印调用及其参数。 Wildfly uses undertow as engine so please add a filter to your undertow configuration to log your request. Wildfly 使用 undertow 作为引擎,因此请在您的 undertow 配置中添加一个过滤器以记录您的请求。 Add to your standalone.xml -> subsystem "undertow" the following configuration:添加到您的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>

Alternatively, you can change your xml configuration with jboss-cli.sh with this script:或者,您可以使用以下脚本使用 jboss-cli.sh 更改 xml 配置:

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

script.cli file:脚本.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

Any call that reaches undertow through the open port should log the data received in your logs and that will help to know if the call reaches the wildfly and be able to trace the problem.通过开放端口到达undertow 的任何呼叫都应记录在您的日志中收到的数据,这将有助于了解呼叫是否到达wildfly 并能够追踪问题。 Debug logs will also be welcome later if the call actually reaches wildfly.如果调用实际到达wildfly,稍后也欢迎调试日志。

On the other hand, have you tested if the problem persists in Wildfly 20?另一方面,您是否测试过 Wildfly 20 中是否仍然存在问题? Updating the wildfly between 18-20 is relatively simple.在 18-20 之间更新 wildfly 相对简单。

Update 2:更新 2:

The request looks good, so I suggest you check the startup logs.该请求看起来不错,因此我建议您检查启动日志。 Seems to be a race condition at start, Wildfly runs many tasks simultaneously to get started ASAP.似乎是开始时的竞争条件,Wildfly 同时运行许多任务以尽快开始。

Typically, when you have duplicate configuration files in classpath or startup codes, it can lead to unexpected behavior, so comparing logs is helpful.通常,当您在类路径或启动代码中有重复的配置文件时,可能会导致意外行为,因此比较日志很有帮助。 Check that you only have a web.xml and file descriptors in your.war file.检查您的.war 文件中是否只有 web.xml 和文件描述符。

Hope I can helps希望我能帮上忙

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM