Você está vendo a documentação do Apigee Edge.
Acesse a
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 este código de resposta:
HTTP/1.1 500 Internal Server Error
Além disso, talvez você veja a seguinte mensagem de erro:
{ "fault":{ "faultstring":"Bad Form Data", "detail":{ "errorcode":"protocol.http.BadFormData" } } }
Dados do formulário
Antes de entrar em detalhes sobre como solucionar esse problema, vamos entender o que são dados de formulário.
Os dados do formulário são as informações fornecidas pelo usuário normalmente por meio de 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 são codificados de acordo com 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 do 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
codificados por porcentagem, ou seja, eles são representados como um trio de caracteres
%HH
, que consiste em um sinal de porcentagem seguido por dois dígitos hexadecimais representando 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 de 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 para o 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
Para transmitir grandes quantidades de dados binários ou textos com caracteres não ASCII, envie os dados com
Content-Type:
multipart/form-data, conforme explicado em 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:
- A solicitação HTTP enviada pelo cliente para o Apigee Edge contém:
Content-Type: application/x-www-form-urlencoded
e- Dados de formulário com o sinal de porcentagem (
%
) ou o sinal de porcentagem (%
) seguido por caracteres hexadecimais inválidos que não são permitidos de acordo com a Seção 17.13.4.1 dos Formulários.
O proxy de API no Apigee Edge lê os parâmetros de formulário específicos que contêm caracteres que não são permitidos para uso no fluxo de solicitação usando a política ExtractVariables ou AttributionMessage.
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, você receberá esse erro.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 de formulário na solicitação têm caracteres não permitidos Os parâmetros do formulário transmitidos como parte da solicitação HTTP pelo cliente contêm caracteres que não têm permissão para uso. Usuários de nuvens públicas e privadas 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 o monitoramento de APIs:
- Faça login na interface do Apigee Edge como usuário com um papel apropriado.
Alterne para a organização em que você quer investigar o problema.
- Navegue até a página Analisar > Monitoramento de API > Investigar.
- Selecione o período específico em que você observou os erros.
Trace o Código de falha em relação a Time.
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.BadFormData
são mostradas 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 de falha seráprotocol.http.BadFormData
e a Política de falha estiver vazia, isso indica que o erro ocorreu enquanto a política específica indicada na Política de falhas estava lendo ou extraindo os dados do formulário (parâmetros do formulário) com caracteres não permitidos para serem usados. - 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 de rastreamento
Para diagnosticar o erro usando a ferramenta Trace:
- Ative a sessão de rastreamento
e:
- Aguarde a ocorrência do erro
500 Internal Server Error
ou - Se for possível reproduzir o problema, faça a chamada de API para reproduzi-lo
500 Internal Server Error
- Aguarde a ocorrência do erro
Verifique se a opção Mostrar todos os FlowInfos está ativada:
- Selecione uma das solicitações com falha e examine o rastro.
- Navegue pelas diferentes fases do rastro e localize onde a falha ocorreu.
Geralmente, o erro aparece em uma das políticas, conforme mostrado abaixo:
No rastro de amostra acima, observe que a falha ocorreu na política ExtractVariables chamada
EV-ExtractFormParams
.Navegue até o fluxo chamado Error depois da política específica que falhou:
- Observe os valores a seguir no rastro:
erro:
Bad Form Data
estado:
PROXY_REQ_FLOW
error.class::
com.apigee.rest.framework.BadRequestException
- O valor do erro
Bad Form Data
indica que os parâmetros do formulário tinham alguns caracteres não permitidos. - 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 rastro e clique nela.
Role para baixo até a seção Stage Details - Error Headers 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.BadFormData
epolicy
, 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), que tinham caracteres não permitidos.Cabeçalhos de resposta Valor X-Apigee-fault-code protocol.http.BadFormData
X-Apigee-fault-source policy
X-Apigee-fault-policy extractvariables/EV-ExtractFormParams
- Neste exemplo, X-Apigee-fault-policy é
extractvariables/EV- ExtractFormParams,
, o que significa que a política ExtractVariables chamadaEV-ExtractFormParams
falhou ao ler ou extrair os parâmetros do formulário.
NGINX
Para diagnosticar o erro usando os registros de acesso do NGINX:
- 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 HTTP
500 Internal Server Error
. Verifique os registros de acesso do NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Pesquise se há algum erro
500
com o códigoprotocol.http.BadFormData
durante um período específico (se o problema aconteceu anteriormente) ou se ainda há alguma solicitação com falha com500
. Se você encontrar erros
500
com 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 amostra 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.BadFormData
X-Apigee-fault-source policy
X-Apigee-fault-policy extractvariables/EV-ExtractFormParams
- 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 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 X-Apigee-fault-policy,. - Neste exemplo, X-Apigee-fault-policy é
extractvariables/EV- ExtractFormParams,
, o que significa que a política ExtractVariables chamadaEV-ExtractFormParams
falhou 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 de
500 Internal Server Error
usando o monitoramento de APIs, a ferramenta de rastreamento 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 valorproxy
oupolicy
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). - Analise a política indicada na Política de falhas e determine as seguintes
informações:
- Fonte: determina se a política está lendo ou extraindo os dados de solicitação ou resposta.
- Parâmetros de formulário:determina os parâmetros específicos do formulário que estão sendo lidos na
política.
Amostra 1
Exemplo 1: política ExtractVariables para extração de parâmetros de formulários:
<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 de formulário:
username
epassword
Isso é indicado pelo elemento
<Pattern>
dentro do elemento<FormParam>
.
Isso indica que os parâmetros do formulário
username
e/oupassword
transmitidos como parte da solicitação HTTP pelo cliente para o Apigee Edge contêm caracteres não permitidos.Amostra 2
Exemplo 2: política AttributionMessage copiando parâmetros do 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:
request
Isso é indicado pelo atributo
source
no elemento<Copy>
.Parâmetros de formulário:
username
epassword
Isso é indicado pelo atributo
name
no elemento<FormParam>
.
Isso indica que os parâmetros do formulário
username
,password
ou ambos transmitidos como parte da solicitação HTTP pelo cliente para o Apigee Edge contêm caracteres não permitidos.
Confira se há caracteres que não têm permissão para o uso nos parâmetros de formulário identificados na etapa 3 com um dos métodos a seguir:
Ferramenta de rastreamento
Para validar usando a ferramenta Trace:
- Se você capturou o rastro 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 de formulário que contêm caracteres
não permitidos para uso fazem parte da solicitação HTTP na
etapa 3 acima, então
- Navegue para a fase Solicitação recebida do cliente.
Role para baixo até a seção Stage Details e analise a seção Request Content.
- No exemplo acima, observe que o parâmetro de formulário
password
conté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 no estado em que se encontra nos dados do formulário. - Portanto, o Apigee Edge responde com
500 Internal Server Error
com o código de erroprotocol.http.BadFormData
.
Solicitação real
Para validar usando a solicitação real, faça o seguinte:
- Se você não tiver acesso à solicitação real feita ao servidor de destino, acesse 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 confira se ele contém caracteres não permitidos, como o sinal de porcentagem (
%
) ou o sinal de porcentagem (%
), seguido de caracteres hexadecimais inválidos.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, observe que o elemento
client_secret
contém o sinal de porcentagem (%
) seguido de caracteres hexadecimais inválidosZY
.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, observe que o elemento
password
contém o sinal de porcentagem (%
), que não pode ser transmitido como está nos dados do formulário.
- Revise o conteúdo dos dados do formulário e confira se ele contém caracteres nã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 Error
com o código de erroprotocol.http.BadFormData
.
Resolução
- Os caracteres especiais nas chaves e nos valores dos dados de formulário ou parâmetros 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.
- Nos exemplos discutidos, corrija os problemas da seguinte maneira:
Amostra 1
Exemplo 1: dados do formulário transmitidos como parte da solicitação:
Use caracteres hexadecimais válidos que correspondam ao código ASCII para 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 a codificação de porcentagem para o sinal de porcentagem (
%
), que é modificar o arquivo para ter%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 as seguintes 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 informações de diagnóstico a seguir 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 o500 Internal Server Error
com o código do erroprotocol.http.BadFormData
- Arquivo de rastreamento das solicitações de API
Se você for um usuário da nuvem privada, forneça as seguintes informações:
- Concluir a mensagem de erro observada para as solicitações com falha
- Nome do ambiente
- Pacote de proxy de API
- Arquivo de rastreamento das 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