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 和文件描述符。

希望我能幫上忙