500 Erro interno do servidor - BadFormData

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X.
informações

Sintoma

O aplicativo cliente recebe um código de status HTTP de 500 Internal Server Error com o código de erro protocol.http.BadFormData como uma resposta para chamadas de API.

Mensagem de erro

O aplicativo cliente recebe o seguinte código de resposta:

HTTP/1.1 500 Internal Server Error

Além disso, você poderá encontrar a seguinte mensagem de erro:

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

Dados do formulário

Antes de nos aprofundarmos na solução desse problema, vamos entender o que são dados de formulário.

Dados de formulário são as informações fornecidas pelo usuário normalmente por meio de um formulário HTML que tem elementos como uma caixa de entrada de texto, um botão ou uma caixa de seleção. Os dados do formulário geralmente são enviados como uma série de como parte de solicitações ou respostas HTTP.

Transmissão de dados do formulário

  1. Content-Type: application/x-www-form-urlencoded
    • Se o tamanho dos dados do formulário for pequeno, os dados serão enviados como pares de chave-valor com:
      • Os caracteres em ambas as chaves codificados conforme as regras explicadas em Formulários: seção 17.13.4.1
      • Cabeçalho Content-Type: application/x-www-form-urlencoded

      Exemplo de solicitação com dados de formulário:

      curl https://HOSTALIAS/somepath -H "Content-Type: application/x-www-form-urlencoded" -d "username=abc@google.com&pasword=secret123"
      
    • Todos os caracteres não alfanuméricos em chaves e valores são por cento codificados, ou seja, são representados como um trio de caracteres %HH, que consiste em um sinal de porcentagem seguido de dois dígitos hexadecimais que representa o código ASCII do caractere específico.
    • Assim, mesmo que o sinal de porcentagem (%) seja permitido nos dados do formulário, ele é interpretado como o início de uma sequência de escape especial. Portanto, se os dados do formulário precisarem contêm o sinal de porcentagem (%) na chave ou no valor, então eles devem ser transmitidos como %25, , que representa o código ASCII do sinal de porcentagem (%).
  2. Content-Type: multipart/form-data

    Se você quiser transmitir grandes quantidades de dados binários ou texto que contenha caracteres não ASCII você poderá enviar os dados com o Content-Type: multipart/form-data, conforme explicado na Formulários: seção 17.13.4.2

Causas possíveis

Esse erro ocorrerá se e somente se todas as condições a seguir forem satisfeitas:

  1. A solicitação HTTP enviada pelo cliente para o Apigee Edge contém:
    1. Content-Type: application/x-www-form-urlencoded e
    2. Dados do formulário com o sinal de porcentagem (%) ou o sinal de porcentagem (%) seguido por caracteres hexadecimais inválidos que não são permitidos Formulários: seção 17.13.4.1.
  2. O proxy de API na Apigee Edge lê os parâmetros específicos do formulário que contêm qualquer caractere que não podem ser usadas no fluxo de solicitação utilizando ExtractVariables ou o atribuição de mensagem.

    Por exemplo, se os dados do formulário contiverem o sinal de porcentagem (%) no estado em que se encontra (sem codificação) ou o sinal de porcentagem (%) seguido por qualquer caractere hexadecimal inválido na chave e/ou valor, esse erro será exibido.

    Estas são as possíveis causas desse erro:

    Causa Descrição Instruções de solução de problemas aplicáveis para
    Os parâmetros do formulário na solicitação têm caracteres não permitidos Os parâmetros de formulário passados como parte da solicitação HTTP pelo cliente contêm qualquer caracteres que não podem ser usados. Usuários de nuvem pública e privada de borda

Etapas comuns do diagnóstico

Use uma das seguintes ferramentas/técnicas para diagnosticar esse erro:

Monitoramento de APIs

Para diagnosticar o erro usando a API Monitoring:

  1. Faça login na interface do Apigee Edge como usuário com uma função apropriada.
  2. Alterne para a organização na qual você deseja investigar o problema.

  3. Navegue até o menu Analisar > Monitoramento de APIs > Investigar.
  4. Selecione o período específico em que você observou os erros.
  5. Compare Código de falha com Time.

  6. Selecione uma célula que tenha o código de falha protocol.http.BadFormData como mostrados abaixo:

    (ampliar imagem)

  7. As informações sobre o código de falha protocol.http.BadFormData são exibido conforme mostrado abaixo:

    (ampliar imagem)

  8. Clique em Ver registros e expanda a linha da solicitação com falha.

  9. Na janela Registros, observe os seguintes detalhes:
    • Código de status: 500
    • Origem da falha: proxy
    • Código da falha:protocol.http.BadFormData
    • Política de falhas:extractvariables/EV-ExtractFormParams
  10. Se a Origem da falha for proxy, o Código da falha será protocol.http.BadFormData e Fault Policy não estiverem vazios, então indica que o erro ocorreu enquanto a política específica indicada em Falhas política era ler ou extrair os dados (parâmetros de formulário) que tinham caracteres que não podem ser usados.
  11. Neste exemplo, X-Apigee-fault-policy é extractvariables/EV- ExtractFormParams, , o que significa que a política ExtractVariables chamada EV-ExtractFormParams falhou ao ler ou extrair o formulário parâmetros.

Ferramenta Trace

Para diagnosticar o erro usando a ferramenta Trace:

  1. Ative a sessão de trace. e:
    • Aguarde a ocorrência do erro 500 Internal Server Error ou
    • Se você puder reproduzir o problema, faça a chamada de API para reproduzir o problema 500 Internal Server Error
  2. Verifique se Mostrar todos os FlowInfos está ativado:

  3. Selecione uma das solicitações com falha e examine o trace.
  4. Navegar pelas diferentes fases do trace e localizar a falha o incidente.
  5. O erro geralmente aparece em uma das políticas, conforme mostrado abaixo:

    No trace de amostra acima, observe que a falha ocorreu Política ExtractVariables chamada EV-ExtractFormParams.

  6. Navegue até o fluxo chamado Error, localizado após a política específica que falhou:

  7. Observe os seguintes valores do trace:

    erro: Bad Form Data

    estado: PROXY_REQ_FLOW

    error.class::com.apigee.rest.framework.BadRequestException

    • O valor do erro Bad Form Data indica que o formulário parâmetros tinham alguns caracteres que não podem ser usados.
    • O valor do estado PROXY_REQ_FLOW, indica que o erro ocorreu no fluxo de solicitação do proxy de API.
  8. Navegue até a fase AX (dados do Analytics registrados) no rastreamento e clique reimplantá-lo.
  9. Role para baixo até a seção Detalhes da fase - Cabeçalhos de erro e determinar os valores de X-Apigee-fault-code, X-Apigee-fault-source, e X-Apigee-fault-policy, conforme mostrado abaixo:

  10. Observe que os valores de X-Apigee-fault-code e X-Apigee-fault-source são protocol.http.BadFormData e policy, respectivamente e X-Apigee-fault-policy não esteja vazio. Isso indica que o erro ocorreu enquanto a política específica indicada na X-Apigee-fault-policy era leitura ou extração dos dados de formulário (parâmetros de formulário), que tinham caracteres que não podem ser usados.

    Cabeçalhos de resposta Valor
    X-Apigee-fault-code protocol.http.BadFormData
    X-Apigee-fault-source policy
    X-Apigee-fault-policy extractvariables/EV-ExtractFormParams
  11. Neste exemplo, X-Apigee-fault-policy é extractvariables/EV- ExtractFormParams, , o que significa que a política ExtractVariables chamada Falha em EV-ExtractFormParams ao ler ou extrair o formulário parâmetros.

NGINX

Para diagnosticar o erro usando registros de acesso do NGINX:

  1. Se você for um usuário da nuvem privada, poderá usar os registros de acesso do NGINX para determinar as principais informações sobre o 500 Internal Server Error do HTTP.
  2. Verifique os registros de acesso do NGINX:

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

  3. Pesquise se há algum erro 500 com o código de erro. protocol.http.BadFormData durante um período específico (se o problema aconteceram) ou se ainda há solicitações com falha 500:
  4. Se você encontrar erros 500 no X-Apigee-fault-code correspondente ao valor de protocol.http.BadFormData, determinar o valor de X-Apigee-fault-source e X-Apigee-fault-policy.

    Exemplo de erro 500 do registro de acesso do NGINX:

    O exemplo de entrada do registro de acesso do NGINX acima tem os seguintes valores para X-Apigee-fault-code e X-Apigee-fault-source:

    Cabeçalhos Valor
    X-Apigee-fault-code protocol.http.BadFormData
    X-Apigee-fault-source policy
    X-Apigee-fault-policy extractvariables/EV-ExtractFormParams
  5. Observe que os valores de X-Apigee-fault-code, X-Apigee-fault-source são protocol.http.BadFormData, policy respectivamente e X-Apigee-fault-policy não esteja vazio. Isso indica que o erro ocorreu enquanto a política específica indicada na X-Apigee-fault-policy, era leitura ou extração dos dados de formulário (parâmetros de formulário), que tinham caracteres que não podem ser usados.
  6. Neste exemplo, X-Apigee-fault-policy é extractvariables/EV- ExtractFormParams, , o que significa que a política ExtractVariables chamada Falha em EV-ExtractFormParams ao ler o formulário parâmetros.

Causa: os parâmetros do formulário na solicitação têm caracteres não permitidos

Diagnóstico

  1. Determine o código da falha, a origem da falha e a política de falhas do 500 Internal Server Error usando o Monitoring de APIs, a ferramenta Trace ou os registros de acesso do NGINX, conforme explicado. em Etapas comuns de diagnóstico.
  2. Se o Código da falha for protocol.http.BadFormData, significa que a Origem da falha o valor proxy ou policy e a Política de falhas não é vazio,,isso indica que a política especificada em , falhou ao Ler ou extrair os dados do formulário (parâmetros de formulário).
  3. Examine a política indicada na Política de falhas e determine o seguinte informações:
    1. Origem:determina se a política está lendo ou extraindo os dados solicitação ou resposta.
    2. Parâmetros do formulário: determine os parâmetros específicos do formulário que estão sendo lidos no política.

      Amostra 1

      Exemplo 1: política ExtractVariables extraindo parâmetros de formulário:

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

      Na política ExtractVariables acima:

      • Fonte: request

        Isso é indicado pelo elemento <Source>

      • Parâmetros do formulário:username e password

        Isso é indicado pelo elemento <Pattern> Elemento <FormParam>

      Isso indica que os parâmetros de formulário username e/ou password transmitido como parte da solicitação HTTP pelo cliente para O Apigee Edge contém caracteres que não podem ser usados.

      Amostra 2

      Exemplo 2: parâmetros de formulário de cópia da política AttributionMessage:

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

      Na política ExtractVariables acima:

      • Origem: request

        Isso é indicado pelo atributo source no Elemento <Copy>

      • Parâmetros do formulário:username e password

        Isso é indicado pelo atributo name no Elemento <FormParam>

      Isso indica que os parâmetros do formulário username ou password ou transmitidos como parte da solicitação HTTP pelo cliente para o Apigee Edge contém qualquer caracteres que não podem ser usados.

  4. Verifique se há algum caractere não permitido no usou caracteres nos parâmetros de formulário identificados na etapa 3; usando um dos seguintes métodos:

    Ferramenta Trace

    Para validar usando a ferramenta Trace:

    1. Se você capturou o rastro da solicitação com falha, conforme explicado nas Etapas comuns de diagnóstico e, em seguida, selecione uma das solicitações com falha.
    2. Se você determinou que os parâmetros do formulário que contêm quaisquer caracteres que não podem ser usadas fazem parte da solicitação HTTP no na etapa 3 acima, depois
      1. Navegue até a fase Solicitação recebida do cliente.
      2. Role para baixo até a seção Detalhes da fase e analise as Solicite o conteúdo.

        ( ver imagem maior)

      3. No exemplo acima, o parâmetro do formulário password contém o sinal de porcentagem (%).
      4. Como o sinal de porcentagem (%) também é usado para a codificação por cento dos caracteres especiais, ele não pode ser usado no estado em que se encontra os dados do formulário.
      5. Portanto, o Apigee Edge responde com 500 Internal Server Error pelo código do erro. protocol.http.BadFormData.

    Solicitação real

    Para validar usando a solicitação real:

    1. Se você não tiver acesso à solicitação real feita ao servidor de destino, e acesse Resolução.
    2. Se você tiver acesso à solicitação real feita ao Apigee Edge, execute as seguintes etapas:
      1. Revise o conteúdo dos dados do formulário e verifique se eles contêm caracteres não podem ser usados, como o sinal de porcentagem (%) ou o sinal de porcentagem (%) seguido por caracteres hexadecimais.

        Amostra 1

        Exemplo de solicitação no 1: dados do formulário como parte da solicitação

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

        Neste exemplo, o elemento client_secret contém o sinal de porcentagem (%) seguido por caracteres hexadecimais inválidos ZY.

        Amostra 2

        Exemplo de solicitação no 2: dados de formulário transmitidos em um arquivo:

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

        Conteúdo de form_data.xml:

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

        Neste exemplo, o elemento password contém o sinal de porcentagem (%), que não deve ser passadas no estado em que se encontram nos dados do formulário.

    3. Nos dois exemplos acima, os dados do formulário enviados como parte da solicitação HTTP para O Apigee Edge contém caracteres que não podem ser usados.
    4. Portanto, o Apigee Edge responde com 500 Internal Server Error pelo código de erro protocol.http.BadFormData.

Resolução

  1. Verifique se todos os caracteres especiais nas chaves e nos valores dos dados ou parâmetros do formulário enviados como parte da solicitação HTTP pelo cliente são sempre codificados conforme explicado em Dados do formulário: application/x-www-form-urlencoded.
  2. Para os exemplos discutidos acima, você pode corrigir os problemas da seguinte maneira:

    Amostra 1

    Exemplo 1: dados do formulário transmitidos como parte da solicitação:

    Use um válido caracteres hexadecimais que correspondem ao código ASCII de um caractere específico. Por exemplo, se você quiser enviar o cifrão ($), use %24. conforme mostrado abaixo:

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

    Amostra 2

    Exemplo de solicitação no 2: dados de formulário transmitidos em um arquivo:

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

    Conteúdo de form_data.xml:

    Use o codificação por cento para o sinal de porcentagem (%), ou seja, modificar o arquivo para têm %25 , como mostrado abaixo:

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

Especificação

O Apigee Edge espera que os dados do formulário sejam enviados de acordo com estas especificações:

Especificação
Dados do formulário: application/x-www-form-urlencoded

Se você ainda precisar de ajuda do suporte da Apigee, acesse Precisa coletar informações de diagnóstico.

É necessário coletar informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, colete as seguintes informações: informações de diagnóstico e entre em contato com o suporte do Apigee Edge:

Se você for um usuário da nuvem pública, forneça as seguintes informações:

  • Nome da organização
  • Nome do ambiente
  • Nome do proxy da API
  • Comando curl completo usado para reproduzir o 500 Internal Server Error pelo código de erro. protocol.http.BadFormData
  • Arquivo de rastreamento para as solicitações de API

Se você for um usuário da nuvem privada, forneça estas informações:

  • Mensagem de erro completa observada para as solicitações com falha
  • Nome do ambiente
  • Pacote de proxy de API
  • Arquivo de rastreamento para as solicitações de API
  • Registros de acesso do NGINX

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

    Onde:ORG, ENV e PORT# são substituídos por valores reais.

  • Registros do sistema do processador de mensagens

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

Referências