Questa pagina si applica a Apigee e Apigee ibrido.
Visualizza la documentazione di
Apigee Edge.
Questo argomento descrive le proprietà di trasporto che possono essere impostate nelle configurazioni TargetEndpoint
e ProxyEndpoint
per controllare il comportamento di messaggistica e connessione. Per la copertura completa delle opzioni di configurazione TargetEndpoint
e ProxyEndpoint
, consulta Riferimento alla configurazione del proxy API.
Proprietà di trasporto TargetEndpoint
L'elemento HTTPTargetConnection
nelle configurazioni TargetEndpoint
definisce un insieme di proprietà di trasporto HTTP. Puoi utilizzare queste proprietà per impostare le configurazioni a livello di trasporto.
Le proprietà sono impostate sugli elementi TargetEndpoint
HTTPTargetConnection
come mostrato in questa configurazione di esempio:
<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>
Specifica della proprietà di trasporto TargetEndpoint
Nome proprietà | Valore predefinito | Descrizione |
---|---|---|
allow.post.without.content.length |
false | Ti consente di inviare richieste POST senza contenuti nel corpo. |
allow.put.without.content.length |
false | Consente di inviare richieste PUT senza contenuti nel corpo. |
allow.tls.session.resumption |
true | Se i client true (predefinito) riutilizzano le sessioni TLS quando si effettuano nuove connessioni alla destinazione.
Imposta su false se non vuoi riutilizzare la sessione TLS. Il riutilizzo delle sessioni in genere comporta tempi di connessione più brevi, ma alcune destinazioni potrebbero non supportare il riutilizzo delle sessioni o avere difficoltà. |
keepalive.timeout.millis |
60.000 | Timeout di inattività della connessione per la connessione di destinazione nel pool di connessioni. Se la connessione nel pool è inattiva oltre il limite specificato, viene chiusa. |
connect.timeout.millis |
3000 |
Timeout connessione di destinazione. Apigee restituisce un codice di stato HTTP |
ignore.allow.header.for.405 |
true |
Consente di ritrasmettere il codice di stato 405 al client. Se abiliti il flag, Apigee restituirà il codice di stato 405 anziché 502. |
io.timeout.millis |
55000 |
Se non esistono dati da leggere per il numero di millisecondi specificato o se il socket non è pronto a scrivere dati per un determinato numero di millisecondi, la transazione viene trattata come un timeout.
|
supports.http11 |
true | Se è true e il client invia una richiesta 1.1 , viene inviata anche una richiesta 1.1 alla destinazione, altrimenti alla destinazione viene inviata una richiesta 1.0 . |
use.proxy |
true | Questa proprietà si applica solo ad Apigee hybrid.
Se il file degli override ibridi di Apigee contiene la configurazione
Se impostato su |
use.proxy.tunneling |
true |
Questa proprietà si applica solo ad Apigee hybrid. Se questo valore è impostato su true e le configurazioni del proxy vengono specificate, il file di override di Apigee ibridi come descritto in Configurare il proxy di inoltro per i proxy API, le connessioni di destinazione vengono impostate in modo da utilizzare il tunnel specificato. Se la destinazione utilizza TLS/SSL, questa proprietà viene ignorata e il messaggio viene sempre inviato utilizzando un tunnel. |
request.streaming.enabled |
false |
Per impostazione predefinita ( |
response.streaming.enabled |
false |
Per impostazione predefinita (false), i payload delle risposte HTTP vengono letti in un buffer e i criteri che possono operare sul payload funzionano come previsto. Nei casi in cui i payload sono maggiori della dimensione del buffer (10 MB in Apigee), puoi impostare questo attributo su true. Se true, i payload della risposta HTTP non vengono letti in un buffer, ma vengono trasmessi così come sono nel flusso di risposta |
success.codes |
N/A |
Per impostazione predefinita, Apigee considera il codice HTTP L'impostazione di questa proprietà sovrascrive i valori predefiniti. Pertanto, se vuoi aggiungere il codice HTTP
Se vuoi che solo il codice HTTP
Se imposti il codice HTTP |
compression.algorithm |
N/A |
Per impostazione predefinita, Apigee rispetta il tipo di compressione impostato (gzip, deflate o nessuno) per i messaggi ricevuti. Se la richiesta viene ricevuta dal client utilizzando, ad esempio, la compressione gzip, Apigee la inoltra alla destinazione utilizzando la compressione gzip. Se la risposta ricevuta dalla destinazione utilizza deflate, Apigee la inoltra al client utilizzando deflate. I valori supportati sono:
Vedi anche: Apigee supporta la compressione/decompressione con la compressione GZIP/deflate? |
request.retain.headers. |
true | Per impostazione predefinita, Apigee conserva sempre tutte le intestazioni HTTP sui messaggi in uscita. Se il criterio viene impostato su true , tutte le intestazioni HTTP presenti nella richiesta in entrata vengono impostate sulla richiesta in uscita. |
request.retain.headers |
N/A | Definisce intestazioni HTTP specifiche della richiesta che devono essere impostate nella richiesta in uscita al servizio di destinazione. Ad esempio, per eseguire il passthrough dell'intestazione User-Agent , imposta il valore di request.retain.headers su User-Agent .
Più intestazioni HTTP vengono specificate come elenco separato da virgole, ad esempio
User-Agent,Referer,Accept-Language . Questa proprietà esegue l'override di
request.retain.headers.enabled . Se il criterio request.retain.headers.enabled viene impostato su false , tutte le intestazioni specificate nella proprietà request.retain.headers rimangono impostate nel messaggio in uscita. |
response.retain.headers. |
true | Per impostazione predefinita, Apigee conserva sempre tutte le intestazioni HTTP sui messaggi in uscita. Se il criterio viene impostato su true , tutte le intestazioni HTTP presenti nella risposta in entrata dal servizio di destinazione vengono impostate sulla risposta in uscita prima che venga passata a ProxyEndpoint . |
response.retain.headers |
N/A | Definisce le intestazioni HTTP specifiche della risposta che devono essere impostate sulla risposta in uscita prima che venga passata all'ProxyEndpoint . Ad esempio, per eseguire il passthrough dell'intestazione Expires , imposta il valore di response.retain.headers su Expires . Più intestazioni HTTP vengono specificate come elenco separato da virgole, ad esempio Expires,Set-Cookie . Questa proprietà esegue l'override di
response.retain.headers.enabled . Se response.retain.headers.enabled è impostato su false , tutte le intestazioni specificate nella proprietà response.retain.headers rimangono impostate nel messaggio in uscita. |
retain.queryparams. |
true | Per impostazione predefinita, Apigee conserva sempre tutti parametri di ricerca nelle richieste in uscita. Se
impostato su true , tutti parametri di ricerca presenti nella richiesta in entrata vengono impostati
nella richiesta in uscita al servizio di destinazione. |
retain.queryparams |
N/A | Definisce parametri di ricerca specifici da impostare sulla richiesta in uscita. Ad esempio, per includere il parametro di query apikey dal messaggio di richiesta, imposta retain.queryparams su apikey . Più parametri di ricerca vengono specificati come elenco separato da virgole, ad esempio apikey,environment . Questa proprietà sostituisce retain.queryparams.enabled . |
Proprietà di trasporto ProxyEndpoint
Gli elementi ProxyEndpoint
HTTPTargetConnection
definiscono un insieme di proprietà di trasporto HTTP. Queste proprietà possono essere utilizzate per impostare configurazioni a livello di trasporto.
Le proprietà sono impostate sugli elementi ProxyEndpoint
HTTPProxyConnection
come mostrato in questa configurazione di esempio:
<ProxyEndpoint name="default"> <HTTPProxyConnection> <BasePath>/v1/weather</BasePath> <Properties> <Property name="request.streaming.enabled">true</Property> </Properties> </HTTPProxyConnection> </ProxyEndpoint>
Intestazioni delle richieste
Una richiesta HTTP in entrata include le intestazioni HTTP inviate dal client.
Le intestazioni con nomi che corrispondono al pattern X-Apigee-*
vengono rimosse dalle richieste in entrata se un client le invia. Questo pattern del nome è riservato ad Apigee.
Specifica della proprietà di trasporto ProxyEndpoint
Nome proprietà | Valore predefinito | Descrizione |
---|---|---|
X-Forwarded-For |
false | Se il criterio viene impostato su true, l'indirizzo IP dell'host virtuale viene aggiunto alla richiesta in uscita come valore dell'intestazione HTTP X-Forwarded-For . |
request.streaming. |
false |
Per impostazione predefinita (false ), i payload delle richieste HTTP vengono letti in un buffer e i criteri che possono operare sul payload funzionano come previsto. Nei casi in cui i payload sono maggiori della dimensione del buffer (10 MB in Apigee), puoi impostare questo attributo su true . Quando true , i payload delle richieste HTTP non vengono letti in un buffer, ma vengono trasmessi così come sono nel flusso di richieste TargetEndpoint . In questo caso, tutti i criteri che operano sul payload nel flusso di richiesta ProxyEndpoint vengono bypassati. Vedi anche
Richieste e
risposte di flussi di dati. |
response.streaming. |
false |
Per impostazione predefinita (false), i payload delle risposte HTTP vengono letti in un buffer e i criteri che possono operare sul payload funzionano come previsto. Nei casi in cui i payload sono maggiori della dimensione del buffer (10 MB in Apigee), puoi impostare questo attributo su true . Quando true , i payload della risposta HTTP non vengono letti in un buffer, ma vengono trasmessi al client così come sono. In questo caso, tutti i criteri che operano sul payload nel flusso di risposta ProxyEndpoint vengono bypassati. Vedi anche
Richieste e
risposte di flussi di dati. |
compression.algorithm |
N/A |
Per impostazione predefinita, Apigee rispetta il tipo di compressione impostato (gzip, deflate o nessuno) per i messaggi ricevuti. Ad esempio, se un client invia una richiesta che utilizza la compressione gzip, Apigee inoltra la richiesta alla destinazione utilizzando la compressione gzip. Puoi configurare gli algoritmi di compressione da applicare esplicitamente impostando questa proprietà su
Vedi anche: Apigee supporta la compressione/decompressione con la compressione GZIP/deflate? |
api.timeout |
N/A |
Configura il timeout per singoli proxy API (in millisecondi) Puoi configurare i proxy API, anche quelli in cui è abilitato il flusso, in modo che scadano dopo un intervallo di tempo specificato con stato
Ad esempio, per configurare un proxy in modo che scada dopo 180.000 millisecondi (tre minuti), aggiungi la seguente proprietà a <Property name="api.timeout">180000</Property> Non puoi impostare questa proprietà con una variabile. |
HTTPHeader.allowDuplicates |
N/A | Utilizza questa impostazione per consentire intestazioni duplicate (per intestazioni specifiche). <HTTPProxyConnection> <Properties> <Property name="HTTPHeader.allowDuplicates">Content-Type,Authorization</Property> </Properties> </HTTPProxyConnection> |
HTTPHeader.multiValued |
N/A | Utilizza questa impostazione per consentire intestazioni duplicate (per intestazioni specifiche). <HTTPProxyConnection> <Properties> <Property name="HTTPHeader.multiValued">Content-Type,Authorization</Property> </Properties> </HTTPProxyConnection> |
Impostazione di io.timeout.millis e api.timeout
Il funzionamento di io.timeout.millis
e api.timeout
è correlato. Per ogni richiesta a un proxy API:
- Ingress (noto anche come bilanciatore del carico interno) invia il proprio valore di timeout al processore di messaggi. Questo valore di timeout è di 300 secondi per impostazione predefinita e non è configurabile.
- Il processore di messaggi imposta quindi
api.timeout
:- Se
api.timeout
non è impostato a livello di proxy, utilizza il timeout impostato dall'oggetto Ingress. - Se
api.timeout
è impostato a livello di proxy, impostalo nel processore di messaggi sul valore inferiore tra il timeout Ingress o il valoreapi.timeout
.
- Se
-
Il valore
api.timeout
specifica la quantità massima di tempo a disposizione di un proxy API per l'esecuzione dalla richiesta API alla risposta.Dopo l'esecuzione di ogni criterio nel proxy API o prima che il processore di messaggi invii la richiesta all'endpoint di destinazione, viene calcolato dal processore di messaggi (
api.timeout
- tempo trascorso dall'inizio della richiesta).Se il valore è inferiore a zero, il tempo massimo per gestire la richiesta è scaduto e il processore di messaggi restituisce un
504 Gateway Timeout
. -
Il valore
io.timeout.millis
specifica il tempo massimo a disposizione dell'endpoint di destinazione per rispondere.Prima di connettersi a un endpoint di destinazione, il processore di messaggi determina il minore tra (
api.timeout
- tempo trascorso dall'inizio della richiesta) eio.timeout.millis
. Quindi, impostaio.timeout.millis
su quel valore.Se si verifica un timeout durante la scrittura della richiesta HTTP o la lettura della risposta HTTP, viene restituito
504 Gateway Timeout
.