НЕ СМОГЛИ! 405 Метод HTTP PUT не поддерживается этим URL-адресом [PactBroker]
При отправке публикации с localhost работает корректно. При использовании с фиксированным IP-адресом возвращается ошибка 405.
<НЕ СМОГЛИ! 405 Метод HTTP PUT не поддерживается этим URL-адресом>
При публикации проверка работает отлично в обоих направлениях.
Запрос генерируется задачей в gradle:
pact {
publish {
pactBrokerUrl = 'http://localhost:80'
pactBrokerUsername = 'admin'
pactBrokerPassword = 'admin'
tags = ['DEV']
} }
Добавьте настройки в ngnix.conf, но он не будет работать.
Пожалуйста помоги!!!
Ответы 2
как патч-решение использует 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/
Работает, таким образом выполняю в конвейере.
Возможно, ваша проблема не в коде, а в его развертывании.
При развертывании кода в среде разработки веб-сервер / веб-сервис обычно прослушивает локальный хост (или 127.0.0.1). Часто это настройка по умолчанию для распределенного программного обеспечения, поскольку она предоставляет службу только одному и тому же компьютеру, сводя к минимуму степень риска (других обращений к вашей службе).
Это означает, что во многих случаях вам необходимо перенастроить веб-сервер или веб-службу для прослушивания входящих адресов, отличных от 127.0.0.1. Например, в Apache HTTPD вы должны изменить файл /etc/httpd/httpd.conf, чтобы изменить строку
Listen 127.0.0.1:80
к
Listen 80
В других системах есть другие значения конфигурации, которые могут потребовать аналогичного обновления, и я бы посмотрел на детали вашей конкретной среды и проверил параметры конфигурации для вашей среды.
Также возможно, что запрос доходит до машины, а служба его прослушивает, но программный брандмауэр отклоняет запрос после того, как он достигает машины, но до того, как он будет передан службе обработки. Опять же, я бы проверил, включен ли программный брандмауэр, и если да, изучите административные параметры, чтобы перенастроить его, позволяя вашим запросам достигать службы, обрабатывающей их.
Изучая эти административные параметры, я бы также посмотрел на параметры конфигурации ведения журнала, так как это поможет вам лучше понять процесс.
В качестве последнего средства вы можете установить (при условии, что это система Linux) WireShark на сервере, чтобы убедиться, что запрос достигает сервера. Иногда проблемы конфигурации вне службы, такие как программные или аппаратные брандмауэры на промежуточных машинах или ошибки в политиках маршрутизации, могут привести к тому, что ваш запрос будет отправлен в неправильную часть сети, и ваша служба (и сервер, на котором он живет) никогда даже не увидит запрос.
Хотя на данный момент нелегко определить, в чем заключается ваша конкретная проблема, эти предложения должны продвинуть вас дальше к работающей системе и могут быть достаточно полными, чтобы справиться со многими из наиболее распространенных проблем.
Удачи!
Не могли бы вы предоставить какой-либо код для конечной точки, на которую вы отправляете запрос?