-2

When sending the publication with localhost, it works correctly. When using it with a fixed IP it is returning error 405.

<FAILED! 405 The HTTP PUT Method is not supported by this URL>

Alone when publishing, the verification works perfectly in both ways.

The request is generated by the task in gradle:

pact {
  publish {
    pactBrokerUrl = 'http://localhost:80'
    pactBrokerUsername = 'admin'
    pactBrokerPassword = 'admin'
    tags = ['DEV']
} }

Add settings to the ngnix.conf but it will not work.

Please help!!!

2 Answers2

0

how patch solution use curl:

curl -v -XPUT -H 'Content-Type: application/json' -u 'admin:admin' -d@c:/pacts/ms-consumer-ms-provider.json http://<IP>:80/pacts/provider/ms-provider/consumer/ms-consumer/version/1.0.0/

Is working, this way I execute it in the pipeline.

0

Perhaps your problem is not in the code, but in its deployment.

When deploying code in a development environment, it is common to have the web server / webservice listen on localhost (or 127.0.0.1). Often this is the default setting for distributed software, as it exposes the service to only the same machine, minimizing the amount of risk (of others calling your service).

This means that in many cases, you need to reconfigure your webserver or web service to listen on inbound addresses other than 127.0.0.1. In Apache HTTPD for example, you would alter the /etc/httpd/httpd.conf file to alter the line

Listen 127.0.0.1:80

to

Listen 80

Other systems have other configuration values which might require a similar update, and I'd look for the details of your particular environment and the validate the configuration settings for your environment.

It is also possible that the request is reaching the machine and the service is listening for it, but a software firewall is discarding the request after it reaches the machine but before it is passed to the handling service. Again, I would verify if a software firewall is enabled, and if so, look into the administrative options to reconfigure it, permitting your requests to reach the service handling them.

While looking into these administrative options, I would also look at the logging configuration options, as this will assist you with more visibility into the process.

As a latter resort, you might want to install (assuming it is a Linux system) WireShark on the server, to validate that the request is reaching the server. Sometimes configuration issues outside of the service, such as software or hardware firewalls in intermediate machines or errors in routing policies, can have your request sent to the wrong part of the network and your service (and the server it lives in) never even sees the request.

While it is not easy to determine what your specific problem is at this point, these suggestions should move you further along toward a running system, and may be complete enough to handle many of the most common problems.

Good Luck!

Edwin Buck
  • 69,361
  • 7
  • 100
  • 138