Loading

405 Not Allowed error while invoking a CloudHub application

公開日: Jul 4, 2024
解決策

SYMPTOM

You have an application running on CloudHub that does listen for a specific method but your requests are coming back with a 405 Not Allowed reply like below

<html> 
 <head> 
  <title>405 Not Allowed</title> 
 </head> 
 <body bgcolor="white"> 
  <center> 
   <h1>405 Not Allowed</h1> 
  </center> 
  <hr> 
  <center>nginx</center> 
 </body> 
</html>

 

CAUSE

There could be couple of causes for this error.

1. Your worker is not responding : The reason why the reply is 405 is because how CloudHubs load balancer works. When the load balancer receives a request it attempts to forward it to a worker behind it. When such worker is unavailable it replies back to the client with a 504 reply if method is a GET, but 405 for any other method. If you attempt to bypass the load balancer and go straight to the worker the request will time out or just be unable to connect.

2. App is using incorrect port : When the CloudHub application gets deployed the following ports are assigned on the Mule worker:

  • http.port is set to 8081

  • https.port is set to 8082

If you are using HTTP endpoint to invoke the API, the shared load balancer (nginx) forwards the request to 8081 port of the application. Similarly, If you are using HTTPS endpoint to invoke the API, the shared load balancer (nginx) forwards the request to 8082 port of the application. If the application is not listening on the port where the shared load balancer (nginx) forwards the request, you will get the above mentioned error.

3. Application HTTP/S listener uses persistent connections: the following sequence of events can cause a sporadic 405:

3.1) Mule Runtime HTTP/S listener closes the TCP connection after the configured "Connection Idle Timeout" expires due to inactivity
3.2) An instant later, while the TCP close request (TCP [FIN,ACK]) is still in transit, the Load Balancer receives an incoming http/s request and decides to forwards it over this connection
3.3) Given the TCP connection is already closed from the CloudHub worker perspective, it sends back a TCP reset ([RST] segment)
3.4) The Load Balancer detects the TCP [RST] and replies back to the client with a 504 reply if method is a GET, or 405 for any other method


SOLUTION

1. Your worker is not responding : You need to work on why your worker is unresponsive. Refer to the Troubleshooting CloudHub applications that return 502/504 responses article.

2. App is using incorrect port : Use the port 8081 in the app for if you want to use HTTP communication. Use the port 8082 in the app for if you want to use HTTPS communication. Please refer this doc for more information https://docs.mulesoft.com/runtime-manager/cloudhub-networking-guide
Example : Sending request to https://sample.us-e2.cloudhub.io/ -> Request will be forwarded to 8082 of the application.
                 Sending request to http://sample.us-e2.cloudhub.io/ -> Request will be forwarded to 8081 of the application.

3. Disable persistent connections on the app HTTP/S listener: this causes each request to be handled over a new connection between the Load Balancer and the CloudHub worker.

For Mule 3.x:

<http:listener-config name="HTTP_Listener_config" host="0.0.0.0" port="8081" usePersistentConnections="false" />

 

For Mule 4.x: 
<http:listener-config name="HTTP_Listener_config" doc:name="HTTP Listener config">
	<http:listener-connection host="0.0.0.0" port="8081" usePersistentConnections="false" />
</http:listener-config>
ナレッジ記事番号

001117765

 
読み込み中
Salesforce Help | Article