Esta página foi traduzida pela API Cloud Translation.

Referência das propriedades do ponto final

Esta página aplica-se ao Apigee e ao Apigee Hybrid.

Veja a documentação do Apigee Edge.

Este tópico descreve as propriedades de transporte que podem ser definidas nas configurações TargetEndpoint e ProxyEndpoint para controlar o comportamento das mensagens e das ligações. Para uma cobertura completa das opções de configuração TargetEndpoint e ProxyEndpoint, consulte a referência de configuração do proxy da API.

Propriedades de transporte do TargetEndpoint

O elemento HTTPTargetConnection nas configurações TargetEndpoint define um conjunto de propriedades de transporte HTTP. Pode usar estas propriedades para definir configurações ao nível do transporte.

As propriedades são definidas nos elementos TargetEndpoint HTTPTargetConnection, como mostrado nesta configuração de exemplo:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <Properties>
      <Property name="request.retain.headers">User-Agent,Referer,Accept-Language</Property>
      <Property name="retain.queryparams">apikey</Property>
    </Properties>
  </HTTPTargetConnection>
</TargetEndpoint>

Especificação da propriedade de transporte TargetEndpoint

Nome da propriedade	Valor predefinido	Descrição
`allow.post.without.content.length`	falso	Permite enviar pedidos POST sem conteúdo no corpo.
`allow.put.without.content.length`	falso	Permite enviar pedidos PUT sem conteúdo no corpo.
`allow.tls.session.resumption`	verdadeiro	Se os clientes `true` (predefinição) reutilizarem sessões TLS quando fizerem novas ligações ao destino. Defina como `false` se não quiser a reutilização da sessão TLS. Geralmente, a reutilização de sessões significa tempos de ligação mais curtos, mas alguns destinos podem não suportar a reutilização de sessões ou ter dificuldades com a mesma.
`keepalive.timeout.millis`	60000	Limite de tempo de inatividade da ligação para a ligação de destino no conjunto de ligações. Se a ligação no conjunto estiver inativa para além do limite especificado, a ligação é fechada.
`connect.timeout.millis`	3000	Limite de tempo da ligação de destino. O Apigee devolve um código de estado HTTP `503` se ocorrer um tempo limite de ligação. Em alguns casos, pode ser devolvido um código de estado HTTP `504` quando `LoadBalancer` é usado na definição TargetServer e ocorre um limite de tempo. Nota: em alguns casos, o Apigee tenta novamente a ligação automaticamente até três vezes. Como resultado, o tempo total de repetição pode exceder o que está configurado para `connect.timeout.millis`.
`ignore.allow.header.for.405`	verdadeiro	Permite-lhe transmitir o código de estado 405 de volta ao cliente. Se ativar a flag, o Apigee devolve 405 em vez do código de estado 502.
`io.timeout.millis`	55000	Se não existirem dados para ler durante o número especificado de milissegundos ou se o soquete não estiver pronto para escrever dados durante um número especificado de milissegundos, a transação é tratada como um limite de tempo. Se ocorrer um tempo limite durante a leitura do pedido HTTP da entrada, é devolvido `408 Request Timeout`. `408 Request Timeout` não é devolvido se ocorrer um limite de tempo enquanto escreve um pedido para o destino. Se ocorrer um limite de tempo ao escrever o pedido HTTP ou ler a resposta HTTP, é devolvido `504 Gateway Timeout`. Consulte o artigo Definir io.timeout.millis e api.timeout.
`supports.http11`	verdadeiro	Se for `true` e o cliente enviar um pedido `1.1`, o destino também recebe um pedido `1.1`. Caso contrário, é enviado um pedido `1.0` para o destino.
`use.proxy`	verdadeiro	Se o ficheiro de substituições do Apigee hybrid contiver a configuração `HTTP_PROXY`, conforme descrito no artigo Configure o encaminhamento de proxy para proxies de API, use esta propriedade para gerir/controlar que proxies não devem usar a configuração de proxy. Se estiver definido como `false`, o proxy de API ignora as configurações do proxy HTTP especificadas no ficheiro de substituições do Apigee Hybrid para ligações de destino definidas no proxy.
`use.proxy.tunneling`	verdadeiro	Se esta opção estiver definida como verdadeira e as configurações de proxy forem especificadas no ficheiro de substituição do Apigee hybrid conforme descrito em Configurar o encaminhamento de proxy para proxies de API, as ligações de destino são definidas para usar o túnel especificado. Se o destino usar TLS/SSL, esta propriedade é ignorada e a mensagem é sempre enviada através de um túnel.
`response.payload. parse.limit`	`10M`	Por predefinição (`10M`). Use a propriedade `response.payload.parse.limit` para definir o tamanho máximo da carga útil que pode ser processada no fluxo de resposta, em megabytes (M). O limite configurável mínimo é de 10 milhões e o limite configurável máximo é de 30 milhões. Se a propriedade não estiver definida, o limite predefinido é de 10 milhões. Consulte também Tamanho do payload da mensagem.
`request.streaming.enabled`	falso	Por predefinição (`false`), as cargas úteis dos pedidos HTTP são lidas num buffer e as políticas que podem operar na carga útil funcionam conforme esperado. Nos casos em que os payloads são maiores do que o tamanho do buffer (10 MB no Apigee), pode definir este atributo como `true`. Quando `true`, as cargas de pedidos HTTP não são lidas num buffer; são transmitidas tal como estão para o ponto final de destino. Neste caso, todas as políticas que operam na carga útil no fluxo de pedidos `TargetEndpoint` são ignoradas. Veja também Pedidos e respostas de streaming.
`response.streaming.enabled`	falso	Por predefinição (falso), as cargas de resposta de HTTP são lidas num buffer e as políticas que podem operar na carga funcionam como esperado. Nos casos em que os payloads são maiores do que o tamanho do buffer (10 MB no Apigee), pode definir este atributo como verdadeiro. Quando é verdadeiro, as cargas de resposta de HTTP não são lidas num buffer; são transmitidas tal como estão para o fluxo de resposta `ProxyEndpoint`. Neste caso, todas as políticas que operam na carga útil no fluxo de resposta `TargetEndpoint` são ignoradas. Veja também Pedidos e respostas de streaming.
`success.codes`	N/A	Por predefinição, o Apigee trata o código HTTP `4XX` ou `5XX` como erros e trata o código HTTP `1XX`, `2XX` e `3XX` como êxito. Esta propriedade permite a definição explícita de códigos de êxito. Por exemplo, `2XX, 1XX, 505` trata todos os códigos de resposta HTTP `100`, `200` e `505` como êxito. A definição desta propriedade substitui os valores predefinidos. Por conseguinte, se quiser adicionar o código HTTP `400` à lista de códigos de êxito predefinidos, defina esta propriedade como: `<Property name="success.codes">1xx,2xx,3xx,400</Property>` Se quiser que apenas o código HTTP `400` seja tratado como um código de êxito, defina a propriedade como: `<Property name="success.codes">400</Property>` Ao definir o código HTTP `400` como o único código de êxito, os códigos `1xx`, `2xx` e `3xx` são tratados como falhas.
`compression.algorithm`	N/A	Por predefinição, o Apigee respeita o tipo de compressão definido (gzip, deflate ou nenhum) para as mensagens recebidas. Se o pedido for recebido do cliente através, por exemplo, da compressão gzip, o Apigee encaminha o pedido para o destino através da compressão gzip. Se a resposta recebida do destino usar deflate, o Apigee encaminha a resposta para o cliente usando deflate. Os valores suportados são: gzip: envie sempre a mensagem com compressão gzip deflate: envie sempre a mensagem com compressão deflate Nenhuma: envie sempre a mensagem sem compressão Veja também: O Apigee suporta a compressão/descompressão com compressão GZIP/deflate?
`request.retain.headers. enabled`	verdadeiro	Por predefinição, o Apigee retém sempre todos os cabeçalhos HTTP nas mensagens de saída. Quando definida como `true`, todos os cabeçalhos HTTP presentes no pedido recebido são definidos no pedido enviado.
`request.retain.headers`	N/A	Define cabeçalhos HTTP específicos do pedido que devem ser definidos no pedido de saída para o serviço de destino. Por exemplo, para transmitir o cabeçalho `User-Agent`, defina o valor de `request.retain.headers` como `User-Agent`. Vários cabeçalhos HTTP são especificados como uma lista separada por vírgulas, por exemplo: `User-Agent,Referer,Accept-Language`. Esta propriedade substitui `request.retain.headers.enabled`. Se `request.retain.headers.enabled` estiver definido como `false`, todos os cabeçalhos especificados na propriedade `request.retain.headers` continuam a ser definidos na mensagem de saída.
`response.retain.headers. enabled`	verdadeiro	Por predefinição, o Apigee retém sempre todos os cabeçalhos HTTP nas mensagens de saída. Quando definido como `true`, todos os cabeçalhos HTTP presentes na resposta de entrada do serviço de destino são definidos na resposta de saída antes de serem transmitidos ao `ProxyEndpoint`.
`response.retain.headers`	N/A	Define cabeçalhos HTTP específicos da resposta que devem ser definidos na resposta de saída antes de ser transmitida ao `ProxyEndpoint`. Por exemplo, para transmitir o cabeçalho `Expires`, defina o valor de `response.retain.headers` como `Expires`. São especificados vários cabeçalhos HTTP como uma lista separada por vírgulas, por exemplo, `Expires,Set-Cookie`. Esta propriedade substitui `response.retain.headers.enabled`. Se `response.retain.headers.enabled` estiver definido como `false`, todos os cabeçalhos especificados na propriedade `response.retain.headers` continuam a ser definidos na mensagem de saída.
`retain.queryparams. enabled`	verdadeiro	Por predefinição, o Apigee retém sempre todos os parâmetros de consulta em pedidos de saída. Quando definido como `true`, todos os parâmetros de consulta presentes no pedido recebido são definidos no pedido enviado para o serviço de destino.
`retain.queryparams`	N/A	Define parâmetros de consulta específicos a definir no pedido de saída. Por exemplo, para incluir o parâmetro de consulta `apikey` na mensagem de pedido, defina `retain.queryparams` como `apikey`. Vários parâmetros de consulta são especificados como uma lista separada por vírgulas, por exemplo, `apikey,environment`. Esta propriedade substitui `retain.queryparams.enabled`.

Propriedades de transporte do ProxyEndpoint

Os elementos ProxyEndpoint HTTPTargetConnection definem um conjunto de propriedades de transporte HTTP. Estas propriedades podem ser usadas para definir configurações ao nível do transporte.

As propriedades são definidas nos elementos ProxyEndpoint HTTPProxyConnection, conforme mostrado nesta configuração de exemplo:

<ProxyEndpoint name="default">
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <Properties>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
  </HTTPProxyConnection>
</ProxyEndpoint>

Cabeçalhos do pedido

Um pedido HTTP de entrada inclui os cabeçalhos HTTP enviados pelo cliente. Os cabeçalhos com nomes que correspondem ao padrão X-Apigee-* são removidos dos pedidos recebidos se um cliente os enviar. Este padrão de nome está reservado para o Apigee.

Especificação da propriedade de transporte ProxyEndpoint

Nome da propriedade	Valor predefinido	Descrição
`X-Forwarded-For`	falso	Quando está definida como verdadeira, o endereço IP do anfitrião virtual é adicionado ao pedido de saída como o valor do cabeçalho HTTP `X-Forwarded-For`.
`request.streaming. enabled`	`false`	Por predefinição (`false`), as cargas úteis dos pedidos HTTP são lidas num buffer e as políticas que podem operar na carga útil funcionam conforme esperado. Nos casos em que os payloads são maiores do que o tamanho do buffer (10 MB no Apigee), pode definir este atributo como `true`. Quando `true`, as cargas de pedidos HTTP não são lidas num buffer. São transmitidas tal como estão para o fluxo de pedidos `TargetEndpoint`. Neste caso, todas as políticas que operam na carga útil no fluxo de pedidos `ProxyEndpoint` são ignoradas. Veja também Pedidos e respostas de streaming.
`request.payload. parse.limit`	`10M`	Por predefinição (`10M`). Use a propriedade `request.payload.parse.limit` para definir o tamanho máximo do payload que pode ser processado no fluxo de pedidos, em megabytes (M). O limite configurável mínimo é de 10 milhões e o limite configurável máximo é de 30 milhões. Se a propriedade não estiver definida, o limite predefinido é de 10 milhões. Consulte também Tamanho do payload da mensagem.
`response.streaming. enabled`	`false`	Por predefinição (falso), as cargas de resposta de HTTP são lidas num buffer e as políticas que podem operar na carga funcionam como esperado. Nos casos em que os payloads são maiores do que o tamanho do buffer (10 MB no Apigee), pode definir este atributo como `true`. Quando `true`, as cargas de resposta de HTTP não são lidas num buffer; são transmitidas tal como estão para o cliente. Neste caso, todas as políticas que operam na carga útil no fluxo de resposta `ProxyEndpoint` são ignoradas. Veja também Pedidos e respostas de streaming.
`compression.algorithm`	N/A	Por predefinição, o Apigee respeita o tipo de compressão definido (gzip, deflate ou nenhum) para as mensagens recebidas. Por exemplo, quando um cliente envia um pedido que usa a compressão gzip, o Apigee encaminha o pedido para o destino usando a compressão gzip. Pode configurar algoritmos de compressão para serem aplicados explicitamente definindo esta propriedade no `TargetEndpoint` ou `ProxyEndpoint`. Os valores suportados são: gzip: envie sempre a mensagem com compressão gzip deflate: envie sempre a mensagem com compressão deflate Nenhuma: envie sempre a mensagem sem compressão Veja também: O Apigee suporta a compressão/descompressão com compressão GZIP/deflate?
`api.timeout`	N/A	Configure o limite de tempo para proxies de API individuais (em milissegundos) Pode configurar proxies de API, mesmo aqueles com o streaming ativado, para expirar após um período especificado com um estado `504 Gateway Timeout`. Importante: o limite de tempo especificado tem de ser inferior ao limite de tempo padrão do processador de mensagens de 300 segundos. Por exemplo, para configurar um proxy para expirar após 180 000 milissegundos (três minutos), adicione a seguinte propriedade a `HTTPProxyConnection`: <Property name="api.timeout">180000</Property> Não pode definir esta propriedade com uma variável. Consulte o artigo Definir io.timeout.millis e api.timeout.
`HTTPHeader.allowDuplicates`	N/A	Use esta definição para permitir cabeçalhos duplicados (para cabeçalhos específicos). <HTTPProxyConnection> <Properties> <Property name="HTTPHeader.allowDuplicates">Content-Type,Authorization</Property> </Properties> </HTTPProxyConnection>
`HTTPHeader.multiValued`	N/A	Use esta definição para permitir cabeçalhos duplicados (para cabeçalhos específicos). <HTTPProxyConnection> <Properties> <Property name="HTTPHeader.multiValued">Content-Type,Authorization</Property> </Properties> </HTTPProxyConnection>

Definir io.timeout.millis e api.timeout

O funcionamento de io.timeout.millis e api.timeout estão relacionados. Em cada pedido a um proxy de API:

O Ingress (também conhecido como equilibrador de carga interno) envia o respetivo valor de tempo limite para o processador de mensagens. Este valor de tempo limite tem como predefinição 300 segundos e não é configurável.
Em seguida, o processador de mensagens define api.timeout:
1. Se api.timeout não estiver definido ao nível do proxy, use o tempo limite definido pelo Ingress.
2. Se api.timeout estiver definido ao nível do proxy, defina-o no processador de mensagens para o menor do limite de tempo de entrada ou o valor de api.timeout.
O valor de api.timeout especifica o tempo máximo que um proxy de API tem para executar desde o pedido API até à resposta.

Após a execução de cada política no proxy da API, ou antes de o processador de mensagens enviar o pedido para o ponto final de destino, o processador de mensagens calcula (api.timeout - tempo decorrido desde o início do pedido).

Se o valor for inferior a zero, significa que o tempo máximo para processar o pedido expirou e o processador de mensagens devolve um 504 Gateway Timeout.
O valor de io.timeout.millis especifica o tempo máximo que o ponto final de destino tem para responder.

Antes de estabelecer ligação a um ponto final de destino, o processador de mensagens determina o menor valor entre (api.timeout – tempo decorrido desde o início do pedido) e io.timeout.millis. Em seguida, define io.timeout.millis para esse valor.

Se ocorrer um limite de tempo ao escrever o pedido HTTP ou ler a resposta HTTP, é devolvido 504 Gateway Timeout.