500 Внутренняя ошибка сервера — BadFormData

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

Симптом

В ответ на вызовы API клиентское приложение получает HTTP-статус 500 Internal Server Error с кодом ошибки protocol.http.BadFormData .

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

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

HTTP/1.1 500 Internal Server Error

Кроме того, вы можете увидеть следующее сообщение об ошибке:

{
   "fault":{
      "faultstring":"Bad Form Data",
      "detail":{
         "errorcode":"protocol.http.BadFormData"
      }
   }
}

Данные формы

Прежде чем перейти к подробному описанию устранения этой проблемы, давайте разберемся, что такое данные формы.

Данные формы — это информация, предоставляемая пользователем, как правило, через HTML-форму, содержащую такие элементы, как текстовое поле ввода, кнопка или флажок. Данные формы обычно передаются в виде последовательности пар «ключ-значение» в рамках HTTP-запросов или ответов.

Передача данных формы

1. Content-Type: application/x-www-form-urlencoded
   • Если размер данных формы невелик, то данные отправляются в виде пар ключ-значение следующим образом:
     • Символы в обоих ключах закодированы в соответствии с правилами, изложенными в разделе «Формы» — Раздел 17.13.4.1.
     • Заголовок Content-Type: application/x-www-form-urlencoded

     Пример запроса с данными из формы:

     curl https://HOSTALIAS/somepath -H "Content-Type: application/x-www-form-urlencoded" -d "username=abc@google.com&pasword=secret123"
     

   • Все небуквенно-цифровые символы как в ключах, так и в значениях кодируются с помощью процентного кодирования , то есть представляются в виде символьной тройки %HH , состоящей из знака процента, за которым следуют две шестнадцатеричные цифры, представляющие ASCII-код конкретного символа.
   • Таким образом, хотя знак процента ( % ) допускается в данных формы, он интерпретируется как начало специальной управляющей последовательности. Следовательно, если данные формы должны содержать знак процента ( % ) в ключе или значении, то его следует передавать как %25, что представляет собой ASCII-код символа процента ( % ).
2. Content-Type: multipart/form-data

   Если вам необходимо передать большие объемы двоичных данных или текста, содержащего символы, отличные от ASCII, вы можете отправить данные с Content-Type: multipart/form-data, как описано в разделе 17.13.4.2 «Формы».

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

Эта ошибка возникает только в том случае, если выполняются все следующие условия:

1. HTTP-запрос, отправленный клиентом в Apigee Edge, содержит:
   1. Content-Type: application/x-www-form-urlencoded , and
   2. В полях данных должен быть указан знак процента ( % ) или знак процента ( % ), за которым следуют недопустимые шестнадцатеричные символы, запрещенные в соответствии с разделом 17.13.4.1 «Формы» .

2. API-прокси в Apigee Edge считывает определенные параметры формы, содержащие любые символы, которые не разрешено использовать в потоке запроса, используя политику ExtractVariables или AssignMessage.

   Например, если данные формы содержат знак процента ( % ) в исходном виде (без кодирования) или знак процента ( % ) Если в ключе и/или значении присутствуют недопустимые шестнадцатеричные символы, вы получите эту ошибку.

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

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

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

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

Причина: Параметры формы в запросе содержат недопустимые символы.

Диагноз

1. Определите код ошибки , источник ошибки и политику обработки ошибок для 500 Internal Server Error используя мониторинг API, инструмент трассировки или журналы доступа NGINX, как описано в разделе «Общие шаги диагностики» .
2. Если код ошибки равен protocol.http.BadFormData , источник ошибки имеет значение proxy или policy , а политика ошибки не пуста , это означает, что политика, указанная в политике ошибки, не сработала при чтении или извлечении данных формы (параметров формы).
3. Изучите политику, указанную в Политике устранения неисправностей , и определите следующую информацию:
   1. Источник: Определите, считывает ли политика данные из запроса или ответа или извлекает их.
   2. Параметры формы: Определите конкретные параметры формы, которые считываются в полисе.

      Образец №1

      Пример №1: Политика ExtractVariables извлекает параметры формы:

            <ExtractVariables name="EV-ExtractFormParms">
               <DisplayName>EV-ExtractFormParams</DisplayName>
               <Source>request</Source>
               <FormParam name="username">
                  <Pattern ignoreCase="false">{username}</Pattern>
               </FormParam>
               <FormParam name="password">
                 <Pattern ignoreCase="false">{password}</Pattern>
               </FormParam>
               <VariablePrefix>forminfo</VariablePrefix>
             <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
            </ExtractVariables>
            

      В указанной выше политике ExtractVariables:

      • Источник: request

        Это указывается элементом <Source>

      • Параметры формы: username и password

        Это указывается элементом <Pattern> внутри элемента <FormParam>

      Это указывает на то, что параметры формы username и/или password передаваемые клиентом в составе HTTP-запроса к Apigee Edge, содержат символы, использование которых запрещено .

      Образец №2

      Пример №2: Политика AssignMessage копирует параметры формы:

            <AssignMessage continueOnError="false" enabled="true" name="AM-CopyFormParams">
              <Copy source="request">
                <FormParams>
                  <FormParam name="username"/>
                  <FormParam name="password"/>
                </FormParams>
              </Copy>
              <AssignTo createNew="true" transport="http" type="request"/>
            </AssignMessage>
            

      В указанной выше политике ExtractVariables:

      • Источник: request

        Это указывается атрибутом source в элементе <Copy>

      • Параметры формы: username и password

        Это указывается атрибутом name в элементе <FormParam>

      Это означает, что параметры формы — username или password , или оба параметра, передаваемые клиентом в составе HTTP-запроса к Apigee Edge, — содержат символы, использование которых запрещено .

4. Проверьте, нет ли в параметрах формы, определенных на шаге 3, каких-либо символов, использование которых запрещено , используя один из следующих методов:

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

   Для проверки с помощью инструмента Trace:

   1. Если вы получили трассировку для неудачного запроса, как описано в разделе «Общие шаги диагностики» , выберите один из неудачных запросов.
   2. Если вы определили, что параметры формы, содержащие какие-либо недопустимые символы, являются частью HTTP-запроса, описанного в шаге 3 выше, то
      1. Перейдите к этапу «Запрос получен от клиента» .

      2. Прокрутите страницу вниз до раздела «Подробности этапа» и ознакомьтесь с содержимым запроса .

         ( Посмотреть увеличенное изображение )

         
      3. В приведенном выше примере обратите внимание, что параметр формы password содержит знак процента ( % ).
      4. Поскольку знак процента ( % ) также используется для кодирования специальных символов в процентах , его нельзя использовать в данных формы в неизмененном виде.
      5. Поэтому Apigee Edge выдает ошибку 500 Internal Server Error с кодом ошибки protocol.http.BadFormData .

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

   Для проверки с использованием фактического запроса:

   1. Если у вас нет доступа к фактическому запросу, отправленному на целевой сервер, перейдите в раздел «Разрешение» .
   2. Если у вас есть доступ к фактическому запросу, отправленному в Apigee Edge, выполните следующие шаги:
      1. Проверьте содержимое данных формы и убедитесь, что оно не содержит символов, которые не разрешено использовать, таких как знак процента ( % ) или знак процента ( % ). за которыми следуют недопустимые шестнадцатеричные символы.

         Образец №1

         Пример запроса №1: Данные формы как часть запроса.

         curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=123456abc123&client_secret=c23578%ZY"
         

         В этом примере обратите внимание, что элемент client_secret содержит знак процента ( % ), за которым следуют недопустимые шестнадцатеричные символы ZY .

         Образец №2

         Пример запроса №2: Данные формы передаются в файле:

         curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d @form_data.xml
         

         Содержимое файла form_data.xml:

         xml=<user><username>abc1234@google.com</username><password>qwerty12345!@#$%</password></user>

         В этом примере обратите внимание, что элемент password содержит знак % ( ), который не следует передавать в данных формы в неизмененном виде.

   3. В двух приведенных выше примерах данные формы, отправляемые в рамках HTTP-запроса в Apigee Edge, содержат символы, использование которых запрещено .
   4. Поэтому Apigee Edge выдает ошибку 500 Internal Server Error с кодом ошибки protocol.http.BadFormData .

Разрешение

1. Убедитесь, что все специальные символы как в ключах, так и в значениях данных формы или параметров, отправляемых клиентом в рамках HTTP-запроса, всегда кодируются, как описано в разделе «Данные формы — application/x-www-form-urlencoded» .
2. В приведенных выше примерах проблемы можно решить следующим образом:

   Образец №1

   Пример №1: Данные формы, передаваемые в рамках запроса:

   Используйте допустимые шестнадцатеричные символы , соответствующие коду ASCII для конкретного символа. Например, если вы хотите отправить знак доллара ( $ ), используйте %24 как показано ниже:

   curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=123456abc123&client_secret=c23578%24"
   

   Образец №2

   Пример запроса №2: Данные формы передаются в файле:

   curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d @form_data.xml
   

   Содержимое файла form_data.xml:

   Используйте процентное кодирование для знака процента ( % ), то есть измените файл так, чтобы он содержал %25 как показано ниже:

   xml=<user><username>abc1234@google.com</username><password>qwerty12345!!@#$%25</password></user>

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

Apigee Edge ожидает, что данные формы будут отправлены в соответствии со следующими спецификациями:

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

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

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

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

• Название организации
• Название среды
• Имя API-прокси
• Полная команда curl , использованная для воспроизведения 500 Internal Server Error с кодом ошибки protocol.http.BadFormData
• Файл трассировки для запросов API

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

• Полное сообщение об ошибке, полученное для неудачных запросов.
• Название среды
• пакет API-прокси
• Файл трассировки для запросов 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

Ссылки

• Типы содержимого форм
• RFC3986, раздел 2.1: Процентное кодирование
• Процент кодирования
• шестнадцатеричные символы