Error interno del servidor: Error de datos del formulario

Estás viendo la documentación de Apigee Edge.
Ve a la Documentación de Apigee X. información

Síntoma

La aplicación cliente obtiene un código de estado HTTP de 500 Internal Server Error con el código de error protocol.http.BadFormData como respuesta a las llamadas a la API.

Mensaje de error

La aplicación cliente obtiene el siguiente código de respuesta:

HTTP/1.1 500 Internal Server Error

Además, puedes observar el siguiente mensaje de error:

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

Datos de formulario

Antes de adentrarnos en los detalles de la solución de este problema, veamos qué son los datos de formularios.

Los datos de un formulario son la información que proporciona el usuario normalmente a través de un formulario HTML con elementos como una casilla de entrada de texto, un botón o una casilla de verificación. Los datos del formulario generalmente se envían como una serie de pares clave-valor como parte de las solicitudes o respuestas HTTP.

Transmisión de datos de formularios

1. Content-Type: application/x-www-form-urlencoded
   • Si el tamaño de los datos del formulario es pequeño, los datos se envían como pares clave-valor con lo siguiente:
     • Los caracteres de ambas claves codificados según las reglas explicadas en Formularios: Artículo 17.13.4.1
     • El encabezado Content-Type: application/x-www-form-urlencoded

     Solicitud de muestra con datos del formulario:

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

   • Todos los caracteres que no sean alfanuméricos en las claves y los valores porcentaje codificado, es decir, se representan como un triplete de caracteres %HH, que consiste en un signo de porcentaje seguido de dos dígitos hexadecimales que representan el código ASCII del carácter específico.
   • Por lo tanto, aunque el signo de porcentaje (%) está permitido en los datos del formulario, es se interpreta como el inicio de una secuencia de escape especial. Por lo tanto, si los datos del formulario deben contienen el signo de porcentaje (%) en la clave o el valor, se deben transmitir como %25, , que representa el código ASCII del signo de porcentaje (%).
2. Content-Type: multipart/form-data

   Si quieres transmitir grandes cantidades de datos binarios o texto que contiene datos no ASCII caracteres, puedes enviar los datos con el Content-Type: multipart/form-data, como se explica en Formularios: Sección 17.13.4.2

Causas posibles

Este error se produce si y solo si se cumplen todas las siguientes condiciones:

1. La solicitud HTTP que envió el cliente a Apigee Edge contiene lo siguiente:
   1. Content-Type: application/x-www-form-urlencoded y
   2. Datos de formulario con el signo de porcentaje (%) o de porcentaje (%) seguido de caracteres hexadecimales no válidos que no se permiten según Formularios: Artículo 17.13.4.1

2. El proxy de API en Apigee Edge lee los parámetros específicos del formulario que contienen cualquier carácter. que no están permitidas para usarse en el flujo de solicitud con las variables ExtractVariables o de la política deAssignMessage.

   Por ejemplo, si los datos del formulario contienen el signo de porcentaje (%) tal como está (sin codificación) o el signo de porcentaje (%) seguido de cualquier hexadecimal no válido caracteres en la clave o el valor, verás este error.

   Estas son las posibles causas de este error:

   Causa	Descripción	Instrucciones de solución de problemas aplicables para
   Los parámetros del formulario de la solicitud tienen caracteres no permitidos	Los parámetros de formulario que pasa el cliente como parte de la solicitud HTTP contienen cualquier caracteres que no están permitidos en uso.	Usuarios perimetrales de nubes públicas y privadas

Pasos comunes de diagnóstico

Usa una de las siguientes herramientas o técnicas para diagnosticar este error:

Causa: Los parámetros de formulario de la solicitud tienen caracteres no permitidos

Diagnóstico

1. Determina el código de errores, la fuente de errores y la política de errores de 500 Internal Server Error con la supervisión de API, la herramienta de seguimiento o los registros de acceso de NGINX como se explica. en Pasos comunes del diagnóstico.
2. Si Fault Code es protocol.http.BadFormData, la Fault Source tiene el valor proxy o policy, y Fault Policy no es vacía, significa que la política especificada en Política de errores falló mientras leer o extraer los datos del formulario (parámetros de formulario).
3. Examina la política indicada en la Política de fallas y determina lo siguiente: información:
   1. Fuente: Determina si la política lee o extrae los datos de solicitud o respuesta.
   2. Parámetros de formulario: Determina los parámetros de forma específicos que se leen en el política de la empresa.

      Ejemplo 1

      Ejemplo 1: Política ExtractVariables que extrae los parámetros del formulario:

            <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>
            

      En la política ExtractVariables anterior, haz lo siguiente:

      • Fuente: request

        Esto se indica con el elemento <Source>.

      • Parámetros del formulario: username y password

        Esto se indica mediante el elemento <Pattern> dentro del Elemento <FormParam>

      Esto indica que los parámetros de forma username o password pasado como parte de la solicitud HTTP del cliente al Apigee Edge contiene caracteres que no están permitidos en su uso.

      Ejemplo 2

      Ejemplo 2: Parámetros del formulario de copia de la política deAssignMessage:

            <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>
            

      En la política ExtractVariables anterior, haz lo siguiente:

      • Origen: request

        Esto se indica mediante el atributo source en el Elemento <Copy>

      • Parámetros del formulario: username y password

        Esto se indica mediante el atributo name en el Elemento <FormParam>

      Esto indica que los parámetros de forma username, password o que el cliente pasa como parte de la solicitud HTTP a Apigee Edge contiene cualquier caracteres que no están permitidos.

4. Comprueba si hay caracteres que no se permiten caracteres usados en los parámetros de forma identificados en el paso 3 con uno de los siguientes métodos:

   Herramienta de seguimiento

   Para validar con la herramienta Trace, haz lo siguiente:

   1. Si capturaste el seguimiento de la solicitud con errores como se explica en Pasos comunes del diagnóstico y, luego, seleccione uno de los para las solicitudes erróneas.
   2. Si determinaste que los parámetros del formulario que contienen caracteres que no pueden usarse son parte de la solicitud HTTP en el paso 3 anterior y, luego,
      .
      1. Navega a la fase Solicitud recibida del cliente.

      2. Desplázate hasta la sección Detalles de la fase y revisa las Solicita Contenido.

         ( ver imagen más grande)

         
      3. En el ejemplo anterior, ten en cuenta que el parámetro de formulario password contiene el signo de porcentaje (%).
      4. Dado que el signo de porcentaje (%) también se usa para codificación porcentual los caracteres especiales, no se puede usar tal como están los datos del formulario.
      5. Por lo tanto, Apigee Edge responde con 500 Internal Server Error por el código de error protocol.http.BadFormData

   Solicitud real

   Para validar con la solicitud real, haz lo siguiente:

   1. Si no tienes acceso a la solicitud real que se hizo al servidor de destino, luego ve a Resolución.
   2. Si tienes acceso a la solicitud real que se hizo a Apigee Edge, realiza sigue estos pasos:
      1. Revisa el contenido de los datos del formulario y fíjate si contiene algún carácter que no se permiten, por ejemplo, el signo de porcentaje (%) o el signo de porcentaje (%) seguido de los caracteres no válidos con caracteres hexadecimales.

         Ejemplo 1

         Solicitud de ejemplo n.o 1: Datos del formulario como parte de la solicitud

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

         En este ejemplo, ten en cuenta que el elemento client_secret contiene el signo de porcentaje (%) seguido del caracteres hexadecimales no válidos ZY.

         Ejemplo 2

         Solicitud de ejemplo n° 2: Datos del formulario pasados en un archivo:

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

         Contenidos de form_data.xml:

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

         En este ejemplo, ten en cuenta que el elemento password contiene el signo de porcentaje (%), que no debe ser y se pasan tal como están en los datos del formulario.

   3. En los dos ejemplos anteriores, los datos del formulario enviados como parte de la solicitud HTTP a Apigee Edge contiene caracteres que no están permitidos en su uso.
   4. Por lo tanto, Apigee Edge responde con 500 Internal Server Error con el código de error protocol.http.BadFormData.

Solución

1. Asegúrate de que se incluyan caracteres especiales en las claves y los valores de los datos o parámetros del formulario que el cliente envía como parte de la solicitud HTTP, siempre se codifican como se explica en Datos de formulario: application/x-www-form-urlencoded.
2. En el caso de los ejemplos que se mencionaron anteriormente, puedes solucionar los problemas de la siguiente manera:

   Ejemplo 1

   Ejemplo 1: Datos del formulario que se pasan como parte de la solicitud:

   Usa válidas caracteres hexadecimales que coinciden con el código ASCII de un carácter específico. Por ejemplo, si quieres enviar el signo de dólar ($), usa %24. como se muestra a continuación:

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

   Ejemplo 2

   Solicitud de ejemplo n° 2: Datos del formulario pasados en un archivo:

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

   Contenidos de form_data.xml:

   Usa el codificación porcentual para el signo de porcentaje (%), que es la modificación del archivo al tienen %25 como se muestra a continuación:

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

Especificación

Apigee Edge espera que los datos de formulario se envíen de acuerdo con las siguientes especificaciones:

Especificación
Datos de formulario: application/x-www-form-urlencoded

Si aún necesitas asistencia del equipo de asistencia de Apigee, ve a Debes recopilar y la información de diagnóstico.

Se debe recopilar información de diagnóstico

Si el problema persiste, incluso después de seguir las instrucciones anteriores, reúne la siguiente información de diagnóstico y, luego, comunícate con el equipo de asistencia de Apigee Edge:

Si eres usuario de la nube pública, proporciona la siguiente información:

• Nombre de la organización
• Nombre del entorno
• Nombre del proxy de API
• Completa el comando curl que se usa para reproducir la 500 Internal Server Error con el código de error protocol.http.BadFormData
• Archivo de seguimiento de las solicitudes a la API

Si eres un usuario de la Nube privada, proporciona la siguiente información:

• Mensaje de error completo observado para las solicitudes fallidas
• Nombre del entorno
• Paquete de proxy de API
• Archivo de seguimiento de las solicitudes a la API

• Registros de acceso de NGINX

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

  Dónde: ORG, ENV y PORT# se reemplazan por valores reales.

• Registros del sistema del procesador de mensajes

  /opt/apigee/var/log/edge-message-processor/logs/system.log

Referencias

• Tipos de contenido del formulario
• RFC3986, sección 2.1: Codificación porcentual
• Codificación porcentual
• Caracteres hexadecimales