400 Неверный запрос — DuplicateHeader

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

Симптом

В ответ на вызовы API клиентское приложение получает HTTP-статус 400 Bad Request с кодом ошибки protocol.http.DuplicateHeader .

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

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

HTTP/1.1 400 Bad Request

Кроме того, вы можете увидеть сообщение об ошибке, похожее на показанное ниже:

{
   "fault":{
      "faultstring":"Duplicate Header \"Expires\"",
      "detail":{
         "errorcode":"protocol.http.DuplicateHeader"
      }
   }
}

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

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

В соответствии с RFC 7230, раздел 3.2.2: Порядок полей , отправитель НЕ ДОЛЖЕН генерировать несколько полей заголовка с одинаковым именем в сообщении, если только полное значение этого поля заголовка не определено как список, разделенный запятыми (например, #(значения)), или если поле заголовка не является известным исключением. Если Apigee Edge обнаруживает определенный заголовок, который не может иметь дубликатов, более одного раза в HTTP-запросе , отправленном клиентом, он отвечает кодом 400 Bad Request и кодом ошибки protocol.http.DuplicateHeader .

Вот возможные причины этой ошибки:

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

Общие этапы диагностики

Для диагностики этой ошибки воспользуйтесь одним из следующих инструментов/методов:

Мониторинг API

Для диагностики ошибки с помощью мониторинга API:

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

  3. Перейдите на страницу Анализ > Мониторинг API > Исследование .
  4. Выберите конкретный временной промежуток, в течение которого вы наблюдали ошибки.
  5. Убедитесь, что для фильтра прокси установлено значение «Все» .
  6. Постройте график зависимости кода ошибки от времени .
  7. Выберите ячейку, содержащую код ошибки protocol.http.DuplicateHeader , как показано ниже:

  8. Информация о коде ошибки protocol.http.DuplicateHeader отображается следующим образом:

  9. Нажмите «Просмотреть журналы» и разверните строку с неудачным запросом.
  10. В окне «Журналы» обратите внимание на следующие сведения:
    1. Код состояния: 400
    2. Источник неисправности: apigee
    3. Код ошибки: protocol.http.DuplicateHeader .
  11. Если источник неисправности имеет значение apigee или MP Если код ошибки имеет значение protocol.http.DuplicateHeader , это означает, что HTTP-запрос от клиента содержал повторяющиеся заголовки.

инструмент трассировки

NGINX

Для диагностики ошибки с помощью журналов доступа NGINX:

  1. Если вы используете частное облако , то можете использовать журналы доступа NGINX для получения ключевой информации об ошибках HTTP 400 .
  2. Проверьте журналы доступа NGINX:

    /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log

    Где: ORG , ENV и PORT# заменяются фактическими значениями.

  3. Выполните поиск, чтобы проверить, были ли какие-либо ошибки 400 за определенный период времени (если проблема возникала в прошлом) или есть ли запросы, которые по-прежнему завершаются с ошибкой 400 .
  4. Если вы обнаружите ошибки 400 с кодом X-Apigee-fault-code, соответствующим значению protocol.http.DuplicateHeader , определите значение X-Apigee-fault-source.

    Пример ошибки 400 из журнала доступа NGINX:

    Приведенная выше запись из журнала доступа NGINX содержит следующие значения для X-Apigee-fault-code и X-Apigee-fault-source:

    Заголовки ответа Ценить
    X-Apigee-fault-code protocol.http.DuplicateHeader
    X-Apigee-fault-source MP

Причина: Дублирующийся заголовок в запросе

Диагноз

  1. Определите код ошибки и источник ошибки, используя мониторинг API или журналы доступа NGINX, как описано в разделе «Общие шаги диагностики» .
  2. Если в поле Fault Source указано значение apigee или MP , это означает, что запрос, отправленный клиентским приложением в Apigee, содержит повторяющиеся заголовки.
  3. Определить фактический заголовок, отправляемый более одного раза в рамках запроса, можно одним из следующих способов:

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

    Используя сообщение об ошибке

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

      Пример сообщения об ошибке:

      "faultstring":"Duplicate Header \"Expires\""
    2. В приведенном выше сообщении об ошибке видно, что заголовок Expires отправляется более одного раза, как это видно из строки faultstring .

    Фактический запрос

    Используя фактический запрос

    1. Если у вас есть доступ к фактическому запросу, отправленному клиентским приложением, выполните следующие действия:

      1. Проверьте список заголовков, переданных в запросе.
      2. Если вы обнаружите, что определенный заголовок встречается в запросе более одного раза с одинаковым или разными значениями, то это и является причиной данной ошибки.

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

      curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT" -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
      

      В приведенном выше примере запроса заголовок Expires отправляется более одного раза. Поэтому этот запрос завершается ошибкой 400 Bad Request и кодом ошибки: protocol.http.DuplicateHeader .

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

Разрешение

Исправление дублирования

Вариант №1 [Рекомендуемый вариант] Исправить клиентское приложение, чтобы оно не включало повторяющиеся заголовки.

  1. Проанализируйте причину отправки клиентом дублирующегося заголовка. Например, в приведенном выше случае Expires . Убедитесь, что API-прокси могут принимать дублирующийся заголовок. Как правило, это нежелательно согласно спецификации HTTP RFC7230 .
  2. Если это нежелательно, внесите изменения в клиентское приложение, чтобы оно не отправляло повторяющиеся заголовки.

    В приведенном выше примере видно, что заголовок Expires отправляется дважды с одним и тем же значением, что нежелательно. Проблему можно исправить, передавая заголовок Expires только один раз, как показано ниже:

    curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
    
  3. Если это необходимо и вы хотите разрешить дублирование заголовков, перейдите к варианту №2 «Использование свойства CwC» .

CwC

Вариант №2. Использование свойства CwC.

Apigee предоставляет свойство CwC HTTPHeader.<HeaderName> , которое позволяет клиентским приложениям и целевым серверам отправлять дублирующиеся заголовки прокси-серверам API в Apigee Edge.

собственность CwC Ценности
HTTPHeader.<HeaderName> allowDuplicates,multivalued

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

HTTPHeader.Expires=allowDuplicates, multiValued
  1. Если вы используете частное облако , вы можете настроить это свойство, чтобы предотвратить выдачу ошибки 400 Bad Request сервисом Apigee Edge, даже если запрос содержит повторяющиеся заголовки, используя руководство по настройке обработчиков сообщений для работы с повторяющимися заголовками .
  2. Если вы являетесь пользователем публичного облака , обратитесь в службу поддержки Apigee Edge , чтобы настроить это свойство для вашей организации.

Спецификация

Согласно следующим спецификациям RFC, Apigee ожидает, что клиентское приложение не будет отправлять повторяющиеся заголовки в рамках запроса:

Спецификация
RFC 7230, раздел 3.2.2: Полевой приказ
RFC 7230, раздел 3.2 Поля заголовка

Если вам по-прежнему нужна помощь службы поддержки Apigee, перейдите по ссылке «Необходимо собрать диагностическую информацию» .

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

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

Если вы являетесь пользователем публичного облака , предоставьте следующую информацию:

  • Название организации
  • Название среды
  • Имя API-прокси
  • Полная команда curl , использованная для воспроизведения ошибки 400
  • Файл трассировки для запросов API

Если вы являетесь пользователем частного облака , предоставьте следующую информацию:

  • Полное сообщение об ошибке, полученное для неудачных запросов.
  • Название среды
  • пакет API-прокси
  • Полная команда curl , которую вы использовали для воспроизведения ошибки 400
  • Файл трассировки для запросов API
  • Журналы доступа NGINX:

    /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log

    Где: ORG , ENV и PORT# заменяются фактическими значениями.

  • Журналы системы обработки сообщений /opt/apigee/var/log/edge-message-processor/logs/system.log