400 Bad request — обычный HTTP-запрос отправлен на HTTPS-порт

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

Симптом

Клиентское приложение получает ответ HTTP 400 Bad Request с сообщением. The plain HTTP request was sent to HTTPS port .

Сообщение об ошибке

Клиентское приложение получает следующий код ответа:

HTTP/1.1 400 Bad Request

Далее следует страница с ошибкой HTML ниже:

<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
</body>
</html>

Возможные причины

Причина Описание Инструкции по устранению неполадок применимы для
HTTP-запрос к виртуальному хосту, настроенному с помощью TLS Клиент отправляет HTTP-запрос на виртуальный хост, настроенный с помощью TLS. Пользователи Edge Public и Private Cloud
HTTP-запрос к целевой конечной точке, настроенной с помощью TLS HTTP-запрос, отправленный на внутренний сервер с поддержкой TLS в целевой конечной точке. Пользователи Edge Public и Private Cloud
Неправильная конфигурация целевого сервера. На целевом сервере настроен безопасный порт 443 но SSL не включен. Пользователи Edge Public и Private Cloud

Причина: HTTP-запрос к виртуальному хосту, настроенному с помощью TLS.

Эта ошибка возникает, когда клиент пытается подключиться к API в Apigee, а упомянутый виртуальный хост настроен на использование SSL и вместо этого получает HTTP-запрос.

Диагностика

Поскольку эта проблема возникает в конечной точке Northbound и запросы API не выполняются при взаимодействии точки входа между клиентским приложением и маршрутизатором, эти сообщения об ошибках не регистрируются в журналах доступа к маршрутизатору NGINX. Таким образом, эти запросы не будут фиксироваться такими инструментами, как мониторинг API и инструмент трассировки.

  1. Проверьте свой запрос API и посмотрите, делаете ли вы HTTP-запрос для псевдонима хоста, который настроен на прием запросов только через безопасный порт 443 . Если да, то это и есть причина проблемы.

    Пример неправильного запроса API:

    curl http://org-test.apigee.net:443/400-demo

    <html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>server</center>
</body>
</html>
  2. Обратите внимание, что в приведенном выше примере запроса HTTP-запрос отправляется к псевдониму хоста myorg-test.apigee.net через защищенный порт 443 . Это причина ошибки 400 Bad Request .

Разрешение

Вам необходимо проверить, использует ли клиент HTTP вместо HTTPs, и сделать правильный запрос, как показано ниже:

Пример запроса API:

curl https://org-test.apigee.net:443/400-demo

или

curl https://org-test.apigee.net/400-demo

< HTTP/1.1 200 OK
< Date: Thu, 25 Feb 2021 13:01:43 GMT
< Content-Type: text/xml;charset=UTF-8
< Content-Length: 403
< Connection: keep-alive
< Server: gunicorn/19.9.0
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true

Причина: HTTP-запрос к целевой конечной точке, настроенной с помощью TLS.

Эта ошибка возникает, если вы неправильно настроили HTTP-запросы к внутреннему серверу с поддержкой TLS в целевой конечной точке прокси-сервера API.

Диагностика

Чтобы диагностировать ошибку с помощью инструмента трассировки, выполните следующие действия:

  1. Включите трассировку в пользовательском интерфейсе Apigee для затронутого прокси-сервера API.
  2. Отправьте запросы к прокси-серверу API.
  3. Выберите один из запросов API, который завершился неудачей с кодом ответа 400 .
  4. Пройдите через различные этапы и определите, где произошел сбой.

  5. Обычно вы увидите ответ об ошибке 400 поступающий от внутреннего сервера. То есть вы увидите ответ об ошибке 400 на этапе «Ответ, полученный от целевого сервера», как показано ниже:

  6. Определите целевую конечную точку, для которой был сделан запрос, щелкнув значок AX (записанные аналитические данные) в трассировке.

  7. Обратите внимание на файл target.url , который содержит протокол, псевдоним хоста внутреннего сервера и иногда номер порта. Порт, используемый для целевого URL-адреса, — 443 , но протокол — HTTP.
  8. Просмотрите определение целевой конечной точки, чтобы понять конфигурацию.

  9. Убедитесь, что хост внутреннего сервера безопасен и прослушивает безопасный порт, например 443 . Если вы используете протокол http в элементе <URL> , это причина этой проблемы.

    Пример конфигурации целевой конечной точки:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TargetEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPTargetConnection>
        <Properties/>
        <URL>http://somehost.org:443/get</URL>
    </HTTPTargetConnection>
</TargetEndpoint>

    В приведенном выше примере показано, что вы используете протокол HTTP, но используется безопасный порт 443 . Это приводит к тому, что внутренний сервер отвечает 400 Bad Request и сообщением об ошибке The plain HTTP request was sent to HTTPS port .

Разрешение

  1. Если ваш внутренний сервер защищен или поддерживает TLS, убедитесь, что вы используете протокол https в элементе <URL> целевой конечной точки, как показано в следующем примере:

    Пример конфигурации целевой конечной точки:

    <HTTPTargetConnection>
    <Properties/>
    <URL>https://somehost.org:443/get</URL>
</HTTPTargetConnection>

  2. Если ваш внутренний сервер небезопасен , то:

    • Не упоминайте номер безопасного порта, например 443 .
    • Вам вообще не нужно указывать номер порта, если ваш внутренний сервер прослушивает стандартный незащищенный порт.
    • Укажите номер порта, если вы используете любой другой незащищенный порт, например: 9080

    Пример конфигурации целевой конечной точки: 

    <HTTPTargetConnection>
    <Properties/>
    <URL>http://somehost.org/get</URL>
</HTTPTargetConnection>

or

<HTTPTargetConnection>
    <Properties/>
    <URL>http://somehost.org:9080/get</URL>
</HTTPTargetConnection>

Причина: неправильная конфигурация целевого сервера.

Если на целевом сервере настроен безопасный порт, например 443 , без включения SSL, это приводит к тому, что процессор сообщений Apigee Edge отправляет HTTP-запросы на безопасный или настроенный с TLS целевой сервер, что приводит к этой проблеме.

Диагностика

Чтобы диагностировать ошибку с помощью инструмента трассировки, выполните следующие действия:

  1. Включите трассировку в пользовательском интерфейсе Apigee для затронутого прокси-сервера API.
  2. Отправьте запросы к прокси-серверу API.
  3. Выберите один из запросов API, который завершился неудачей с кодом ответа 400 .
  4. Пройдите через различные этапы и определите, где произошел сбой.

  5. Обычно вы увидите ответ об ошибке 400 поступающий от внутреннего сервера. То есть вы увидите ответ об ошибке 400 на этапе ответа, полученного от целевого сервера, как показано ниже:

  6. Определите целевую конечную точку, для которой был сделан запрос, щелкнув значок AX (записанные аналитические данные) в трассировке.

  7. Обратите внимание на target.name , который представляет имя целевой конечной точки.

    В приведенном выше примере файла трассировки target.name имеет значение по умолчанию . Это указывает на то, что для этого запроса используется целевая конечная точка по умолчанию.

  8. Просмотрите определение целевой конечной точки, чтобы понять конфигурацию.

    Пример конфигурации целевой конечной точки: 

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TargetEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPTargetConnection>
        <Properties/>
        <LoadBalancer>
        <Server name="faulty-target"/>
        </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

    Приведенный выше пример конфигурации целевой конечной точки показывает, что вы используете целевой сервер с именем faulty-target .

  9. Получив имя целевого сервера, вы можете использовать один из следующих методов для проверки конфигурации целевого сервера:

    • Пограничный интерфейс
    • API управления

Пограничный интерфейс

  1. Перейдите в Apigee Edge > Администратор > Среды > Целевые серверы .
  2. Выберите конкретный целевой сервер, указанный в прокси-сервере API, и нажмите « » .
  3. Проверьте порт, указанный для целевого сервера, и информацию SSL.

  4. Если на целевом сервере настроен безопасный порт (например: 443 ), но SSL не включен, то это и есть причина данной проблемы.

    Как вы можете видеть на снимке экрана выше, используемый порт — 443 но SSL не включен для этого порта в конфигурации целевого сервера. Это заставляет процессор сообщений Apigee Edge отправлять HTTP-запросы на безопасный порт 443 . Таким образом, вы получаете сообщение об ошибке 400 Bad Request с сообщением The plain HTTP request was sent to HTTPS port .

API управления

  1. Выполните API-интерфейс Get target server , чтобы получить подробную информацию о конкретной конфигурации целевого сервера, как показано ниже:

    Пользователь публичного облака: 

    curl -v 'https://api.enterprise.apigee.com/v1/organizations/ORG_NAME/environments/ENV_NAME>/targetservers/TARGET_SERVER_NAME' \
-H "Content-Type:application/xml" \
-H "Authorization:Bearer $TOKEN"

    Пользователь частного облака: 

    curl -v 'http://MANAGEMENT_IP:8080/v1/organizations/ORG_NAME/environments/ENV_NAME/targetservers/TARGET_SERVER_NAME' \
-H "Content-Type:application/xml" \
-H "Authorization:Bearer $TOKEN"
  2. Проверьте порт, указанный для целевого сервера, и информацию SSL.

  3. Если на целевом сервере настроен безопасный порт (например: 443 ), но раздел SSLInfo не определен или не включен, то это и есть причина данной проблемы.

    Пример конфигурации целевого сервера: 

    {
  "host" : "somehost.org",
  "isEnabled" : true,
  "name" : "faulty-target",
  "port" : 443
}

    В приведенном выше примере вывода мы видим, что порт, используемый для целевого соединения, — 443 , но блок конфигурации SSLInfo отсутствует.

    Это заставляет процессор сообщений Apigee Edge отправлять HTTP-запросы на безопасный порт 443 . Таким образом, вы получаете сообщение об ошибке 400 Bad Request с сообщением The plain HTTP request was sent to HTTPS port .

Разрешение

Если ваш целевой сервер защищен или настроен на TLS, вам необходимо включить SSL для конкретного целевого сервера.

Вы можете сделать это, используя один из следующих вариантов:

  • Пограничный интерфейс
  • API управления

Пограничный интерфейс

  1. Перейдите к целевому серверу в Edge UI > Администрирование > Среды > Целевые серверы .
  2. Выберите конкретный целевой сервер и нажмите « .
  3. Если ваш целевой сервер защищен и использует такой порт, как 443 , включите SSL, установив флажок рядом с опцией SSL.
  4. Настройте хранилище доверенных сертификатов , шифры и протоколы . (Только при необходимости)

API управления

Используйте API управления для настройки целевого сервера, как описано в документации по настройке обновления целевого сервера .

Необходимо собрать диагностическую информацию

Если проблема не устранена даже после выполнения приведенных выше инструкций, соберите следующую диагностическую информацию, а затем обратитесь в службу поддержки Apigee Edge .

  1. Если вы являетесь пользователем Public Cloud , предоставьте следующую информацию:
    • Название организации
    • Имя среды
    • Имя прокси API
    • Завершите команду Curl, чтобы воспроизвести ошибку.
    • Отслеживание результатов инструмента (если вам удалось записать неудачный запрос)
  2. Если вы являетесь пользователем частного облака , предоставьте следующую информацию:
    • Обнаружено полное сообщение об ошибке
    • Имя среды
    • Пакет прокси API
    • Определение целевого сервера (если вы используете целевой сервер в своей конечной точке)
    • Отслеживание результатов инструмента (если вам удалось записать неудачный запрос)