Você está lendo a documentação do Apigee Edge.
Acesse a documentação da
Apigee X. info
Sintoma
O aplicativo cliente recebe um código de status HTTP 500 Internal Server Error com
o código de erro protocol.http.BadFormData como 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ê pode receber a seguinte mensagem de erro:
{
"fault":{
"faultstring":"Bad Form Data",
"detail":{
"errorcode":"protocol.http.BadFormData"
}
}
}Dados do formulário
Antes de entrarmos em detalhes sobre como resolver esse problema, vamos entender o que são dados de formulário.
Os dados de formulário são as informações fornecidas pelo usuário, geralmente por um formulário HTML com 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 pares de chave-valor como parte de solicitações ou respostas HTTP.
Transmissão de dados de formulário
- Content-Type: application/x-www-form-urlencoded
- Se o tamanho dos dados do formulário for pequeno, eles serão enviados como pares de chave-valor com:
- Os caracteres nas duas chaves codificados de acordo com as regras explicadas em Forms: seção 17.13.4.1
- O 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 nas chaves e nos valores são
codificados por porcentagem, ou seja, são representados como um tripleto de caracteres
%HH, consistindo em um sinal de porcentagem seguido por dois dígitos hexadecimais que representam 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 conter o sinal de porcentagem (%) na chave ou no valor, eles deverão ser transmitidos como%25,, que representa o código ASCII do caractere de sinal de porcentagem (%).
- Se o tamanho dos dados do formulário for pequeno, eles serão enviados como pares de chave-valor com:
- Content-Type: multipart/form-data
Se você quiser transmitir grandes quantidades de dados binários ou texto com caracteres não ASCII, envie os dados com o
Content-Type:multipart/form-data, conforme explicado em Forms: seção 17.13.4.2
Causas possíveis
Esse erro ocorrerá se e somente se todas as condições a seguir forem satisfeitas:
- A solicitação HTTP enviada pelo cliente ao Apigee Edge contém:
Content-Type: application/x-www-form-urlencodede- Dados de formulário com o sinal de porcentagem (
%) ou o sinal de porcentagem (%) seguido de caracteres hexadecimais inválidos que não são permitidos de acordo com Forms: seção 17.13.4.1.
O proxy de API no Apigee Edge lê os parâmetros de formulário específicos que contêm caracteres não permitidos no fluxo de solicitação usando a política ExtractVariables ou AssignMessage.
Por exemplo, se os dados do formulário contiverem o sinal de porcentagem (
%) sem codificação ou o sinal de porcentagem (%) seguido de caracteres hexadecimais inválidos na chave e/ou no valor, esse erro vai aparecer.Confira as possíveis causas para esse erro:
Causa Descrição Instruções de solução de problemas aplicáveis para Os parâmetros de formulário na solicitação têm caracteres não permitidos Os parâmetros de formulário transmitidos como parte da solicitação HTTP pelo cliente contêm caracteres que não podem ser usados. Usuários da nuvem pública e privada do Edge
Etapas comuns do diagnóstico
Use uma das seguintes ferramentas/técnicas para diagnosticar esse erro:
Monitoramento de APIs
Para diagnosticar o erro usando o API Monitoring:
- Faça login na interface do Apigee Edge como um usuário com um papel adequado.
Mude para a organização em que você quer investigar o problema.
- Acesse a página Analisar > Monitoramento de APIs > Investigar.
- Selecione o período específico em que você observou os erros.
Crie um gráfico com Código de falha e Tempo.
Selecione uma célula com o código de falha
protocol.http.BadFormData, conforme mostrado abaixo:
As informações sobre o código de falha
protocol.http.BadFormDatasão mostradas conforme abaixo:
Clique em Ver registros e expanda a linha da solicitação com falha.
- Na janela Registros, observe os seguintes detalhes:
- Código de status:
500 - Origem da falha:
proxy - Código de falha:
protocol.http.BadFormData - Política de falhas:
extractvariables/EV-ExtractFormParams
- Código de status:
- Se a Origem da falha for
proxy, o Código da falha seráprotocol.http.BadFormDatae a Política de falha não estará vazia. Isso indica que o erro ocorreu enquanto a política específica indicada em Política de falha estava lendo ou extraindo os dados do formulário (parâmetros do formulário) que têm caracteres não permitidos. - 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 os parâmetros do formulário.
Ferramenta Trace
Para diagnosticar o erro usando a ferramenta Trace:
- Ative a sessão de rastreamento e faça uma destas ações:
- Aguarde o erro
500 Internal Server Errorocorrer ou - Se for possível reproduzir o problema, faça a chamada de API para reproduzir o problema
500 Internal Server Error
- Aguarde o erro
Verifique se a opção Mostrar todos os FlowInfos está ativada:
- Selecione uma das solicitações com falha e examine o rastreamento.
- Navegue pelas diferentes fases do rastreamento e localize onde a falha ocorreu.
O erro geralmente aparece em uma das políticas, conforme mostrado abaixo:
No rastreamento de exemplo acima, observe que a falha ocorreu na política ExtractVariables chamada
EV-ExtractFormParams.Navegue até o fluxo chamado Error após a política específica que falhou:
- Observe os valores a seguir no rastreamento:
erro:
Bad Form Datastate:
PROXY_REQ_FLOWerror.class::
com.apigee.rest.framework.BadRequestException- O valor do erro
Bad Form Dataindica que os parâmetros do formulário 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.
- O valor do erro
- Navegue até a fase AX (dados do Analytics registrados) no rastreamento e clique nela.
Role a tela para baixo até a seção Detalhes da fase - Cabeçalhos de erro e determine os valores de X-Apigee-fault-code, X-Apigee-fault-source e X-Apigee-fault-policy, conforme mostrado abaixo:
Os valores de X-Apigee-fault-code e X-Apigee-fault-source são
protocol.http.BadFormDataepolicy, respectivamente, e X-Apigee-fault-policy não está vazio. Isso indica que o erro ocorreu enquanto a política específica indicada em X-Apigee-fault-policy estava lendo ou extraindo os dados do formulário (parâmetros do formulário), que tinham caracteres não permitidos.Cabeçalhos de resposta Valor X-Apigee-fault-code protocol.http.BadFormDataX-Apigee-fault-source policyX-Apigee-fault-policy extractvariables/EV-ExtractFormParams- Neste exemplo, X-Apigee-fault-policy é
extractvariables/EV- ExtractFormParams,, o que significa que a política ExtractVariables chamadaEV-ExtractFormParamsfalhou ao ler ou extrair os parâmetros do formulário.
NGINX
Para diagnosticar o erro usando registros de acesso do NGINX:
- Se você for um usuário do Private Cloud, poderá usar os registros de acesso do NGINX para determinar as principais informações sobre
500 Internal Server ErrorHTTP. Verifique os registros de acesso do NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log- Pesquise para ver se há erros
500com o código de erroprotocol.http.BadFormDatadurante um período específico (se o problema aconteceu no passado) ou se ainda há solicitações com falha500. Se você encontrar erros de
500com o X-Apigee-fault-code correspondente ao valor deprotocol.http.BadFormData, determine o valor de X-Apigee-fault-source e X-Apigee-fault-policy.Exemplo de erro 500 do registro de acesso do NGINX:
A entrada de exemplo acima do registro de acesso do NGINX tem os seguintes valores para X-Apigee-fault-code e X-Apigee-fault-source:
Cabeçalhos Valor X-Apigee-fault-code protocol.http.BadFormDataX-Apigee-fault-source policyX-Apigee-fault-policy extractvariables/EV-ExtractFormParams- Os valores de X-Apigee-fault-code e X-Apigee-fault-source são
protocol.http.BadFormDataepolicy, respectivamente, e X-Apigee-fault-policy não está vazio. Isso indica que o erro ocorreu enquanto a política específica indicada em X-Apigee-fault-policy estava lendo ou extraindo os dados do formulário (parâmetros do formulário), que tinham caracteres não permitidos. - Neste exemplo, X-Apigee-fault-policy é
extractvariables/EV- ExtractFormParams,, o que significa que a política ExtractVariables chamadaEV-ExtractFormParamsfalhou ao ler os parâmetros do formulário.
Causa: os parâmetros do formulário na solicitação têm caracteres não permitidos
Diagnóstico
- Determine o código de falha, a origem da falha e a política de falha para
500 Internal Server Errorusando o Monitoramento de APIs, a ferramenta Trace ou os registros de acesso do NGINX, conforme explicado em Etapas comuns de diagnóstico. - Se o Código de falha for
protocol.http.BadFormData, a Origem da falha tiver o valorproxyoupolicy, e a Política de falha não estiver vazia, isso indica que a política especificada em Política de falha falhou ao ler ou extrair os dados do formulário (parâmetros do formulário). - Examine a política indicada em Política de falha e determine as seguintes informações:
- Origem:determine se a política está lendo ou extraindo os dados da solicitação ou resposta.
- Parâmetros de formulário:determine os parâmetros específicos que estão sendo lidos na política.
Exemplo 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:
requestIsso é indicado pelo elemento
<Source>.Parâmetros de formulário:
usernameepasswordIsso é indicado pelo elemento
<Pattern>no elemento<FormParam>.
Isso indica que os parâmetros de formulário
usernamee/oupasswordtransmitidos como parte da solicitação HTTP pelo cliente para o Apigee Edge contêm caracteres que não podem ser usados.Exemplo 2
Exemplo 2: política AssignMessage copiando parâmetros de formulário:
<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:
requestIsso é indicado pelo atributo
sourceno elemento<Copy>.Parâmetros de formulário:
usernameepasswordIsso é indicado pelo atributo
nameno elemento<FormParam>.
Isso indica que os parâmetros de formulário
usernameoupassword, ou ambos, transmitidos como parte da solicitação HTTP pelo cliente para o Apigee Edge contêm caracteres que não podem ser usados.
Verifique se há caracteres não permitidos nos parâmetros de formulário identificados na etapa 3 usando um dos seguintes métodos:
Ferramenta Trace
Para validar usando a ferramenta Trace:
- Se você capturou o trace da solicitação com falha, conforme explicado em Etapas comuns de diagnóstico, selecione uma das solicitações com falha.
- Se você determinou que os parâmetros do formulário que contêm caracteres
não permitidos fazem parte da solicitação HTTP na
etapa 3 acima, então
- Acesse a fase Solicitação recebida do cliente.
Role a tela para baixo até a seção Detalhes da fase e analise o Conteúdo da solicitação.
- No exemplo acima, observe que o parâmetro de formulário
passwordcontém o sinal de porcentagem (%). - Como o sinal de porcentagem (
%) também é usado para codificação de porcentagem dos caracteres especiais, ele não pode ser usado como está nos dados do formulário. - Portanto, o Apigee Edge responde com
500 Internal Server Errore o código de erroprotocol.http.BadFormData.
Solicitação real
Para validar usando a solicitação real:
- Se você não tiver acesso à solicitação real feita ao servidor de destino, vá para Resolução.
- Se você tiver acesso à solicitação real feita ao Apigee Edge, siga estas etapas:
- Revise o conteúdo dos dados do formulário e verifique se ele contém caracteres que não são permitidos, como o sinal de porcentagem (
%) ou o sinal de porcentagem (%) seguido de caracteres hexadecimais inválidos.Exemplo 1
Exemplo de solicitação nº 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, observe que o elemento
client_secretcontém o sinal de porcentagem (%) seguido de caracteres hexadecimais inválidosZY.Exemplo 2
Exemplo de solicitação nº 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, observe que o elemento
passwordcontém o sinal de porcentagem (%), que não deve ser transmitido como está nos dados do formulário.
- Revise o conteúdo dos dados do formulário e verifique se ele contém caracteres que não são permitidos, como o sinal de porcentagem (
- 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.
- Portanto, o Apigee Edge responde com
500 Internal Server Errore o código de erroprotocol.http.BadFormData.
Resolução
- Verifique se todos os caracteres especiais nas chaves e nos valores de dados ou parâmetros de formulário enviados como parte da solicitação HTTP pelo cliente estão sempre codificados conforme explicado em Dados de formulário - application/x-www-form-urlencoded.
- Para os exemplos discutidos acima, você pode corrigir os problemas da seguinte maneira:
Exemplo 1
Exemplo 1: dados do formulário transmitidos como parte da solicitação
Use caracteres hexadecimais válidos que correspondam ao código ASCII de um caractere específico. Por exemplo, se você quiser enviar o cifrão (
$), use%24conforme mostrado abaixo:curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=123456abc123&client_secret=c23578%24"
Exemplo 2
Exemplo de solicitação nº 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 a codificação por porcentagem para o sinal de porcentagem (
%), ou seja, modifique o arquivo para ter%25, conforme 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 as seguintes especificações:
| Especificação |
|---|
| Dados de formulário: application/x-www-form-urlencoded |
Se você ainda precisar de ajuda do suporte da Apigee, acesse Precisa de 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, reúna as seguintes 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 de API
- Comando
curlcompleto usado para reproduzir o500 Internal Server Errorcom o código de erroprotocol.http.BadFormData - Arquivo de rastreamento para as solicitações de API
Se você for um usuário da nuvem privada, forneça as seguintes 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_logEm que: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