Riferimento per le proprietà degli endpoint

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Questo argomento descrive le proprietà di trasporto che possono essere impostate nelle configurazioni TargetEndpoint e ProxyEndpoint per controllare il comportamento della messaggistica e della connessione. Per la copertura completa della configurazione di TargetEndpoint e ProxyEndpoint, consulta il riferimento sulla 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 configurazioni a livello di trasporto.

Le proprietà vengono impostate sugli elementi HTTPTargetConnection di TargetEndpoint come mostrato di seguito:

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

Specifiche della proprietà di trasporto TargetEndpoint

Nome proprietà Valore predefinito Descrizione
keepalive.timeout.millis 60000 Timeout di inattività della connessione per la connessione di destinazione nel pool di connessioni. Se la connessione nel pool è inattiva oltre il limite specificato, la connessione viene chiusa.
connect.timeout.millis

3000

Timeout connessione di destinazione. Edge restituisce un codice di stato HTTP 503 se si verifica un timeout della connessione.
io.timeout.millis 55000

Se non ci sono dati da leggere per il numero di millisecondi specificato o se il socket non è pronto a scrivere dati per il numero specificato di millisecondi, la transazione viene trattata come un timeout.

  • Se si verifica un timeout durante la scrittura della richiesta HTTP, viene restituito 408, Request Timeout.
  • Se si verifica un timeout durante la lettura della risposta HTTP, viene restituito 504, Gateway Timeout.

Questo valore deve essere sempre inferiore al valore della proprietà proxy_read_timeout dell'host virtuale.

Questo valore deve essere inferiore al timeout utilizzato dal router per la comunicazione con il processore di messaggi. Per saperne di più, consulta Configurazione del timeout del router.

Consulta Impostazione di io.timeout.millis e api.timeout per Edge per saperne di più.
supports.http10 true Se questo è true e il client invia una richiesta 1.0, al target viene inviata anche una richiesta 1.0. In caso contrario, viene inviata una richiesta 1.1 alla destinazione.
supports.http11 true Se questo è true e il client invia una richiesta 1.1, al target viene inviata anche una richiesta 1.1, altrimenti la richiesta 1.0 viene inviata alla destinazione.
use.proxy true Se il criterio viene impostato su true e le configurazioni proxy sono specificate in http.properties (solo deployment on-premise), le connessioni di destinazione vengono impostate in modo da utilizzare il proxy specificato.
use.proxy.tunneling true Se il criterio è impostato su true e le configurazioni proxy sono specificate in http.properties (solo deployment on-premise), le connessioni di destinazione vengono impostate per utilizzare il tunnel specificato. Se la destinazione utilizza TLS/SSL, questa proprietà viene ignorata e il messaggio viene sempre inviato tramite un tunnel.
enable.method.override false Per il metodo HTTP specificato, imposta un'intestazione X-HTTP-Method-Override nella richiesta in uscita al servizio di destinazione. Ad esempio, <Property name="GET.override.method">POST</Property>
*.override.method N/A Per il metodo HTTP specificato, imposta un'intestazione X-HTTP-Method-Override nella richiesta in uscita. Ad esempio, <Property name="GET.override.method">POST</Property>
request.streaming.enabled false

Per impostazione predefinita (false), i payload delle richieste HTTP vengono letti in un buffer e i criteri in grado di operare sul payload funzionano come previsto. Nei casi in cui i payload siano superiori alla dimensione del buffer (10 MB), 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 all'endpoint di destinazione. In questo caso, tutti i criteri che operano sul payload nel flusso di richieste TargetEndpoint vengono ignorati. Vedi anche Richieste e risposte di flussi di dati.
response.streaming.enabled false

Per impostazione predefinita (false), i payload delle risposte HTTP vengono letti in un buffer e i criteri in grado di operare sul payload funzionano come previsto. Nei casi in cui i payload siano superiori alla dimensione del buffer (10 MB), puoi impostare questo attributo su true. Quando true, i payload della risposta HTTP non vengono letti in un buffer, ma vengono trasmessi così come sono nel flusso di risposta ProxyEndpoint. In questo caso, tutti i criteri che operano sul payload nel flusso di risposta di TargetEndpoint vengono ignorati. Vedi anche Richieste e risposte di flussi di dati.
success.codes N/A

Per impostazione predefinita, Apigee Edge considera il codice HTTP 4XX o 5XX come errori e il codice HTTP 1XX, 2XX e 3XX come operazione riuscita. Questa proprietà consente la definizione esplicita dei codici di operazione riuscita; ad esempio, 2XX, 1XX, 505 considera tutti i codici di risposta HTTP 100, 200 e 505 riusciti.

L'impostazione di questa proprietà sovrascrive i valori predefiniti. Pertanto, se vuoi aggiungere il codice HTTP 400 all'elenco dei codici di operazione riuscita predefiniti, imposta questa proprietà come:

<Property name="success.codes">1XX,2XX,3XX,400</Property>

Se vuoi che solo il codice HTTP 400 venga considerato un codice di operazione riuscita, imposta la proprietà come:

<Property name="success.codes">400</Property>

Se imposti il codice HTTP 400 come unico codice valido, i codici 1XX, 2XX e 3XX vengono trattati come errori.
compression.algorithm N/A Per impostazione predefinita, Apigee Edge inoltra le richieste al target utilizzando lo stesso tipo di compressione della richiesta del client. Se la richiesta viene ricevuta dal client utilizzando, ad esempio, la compressione gzip, Apigee Edge inoltra la richiesta al target utilizzando la compressione gzip. Se la risposta ricevuta dal target utilizza il valore deflate, Apigee Edge inoltra la risposta al client utilizzando il valore deflate. I valori supportati sono:
  • gzip: invia sempre i messaggi utilizzando la compressione gzip
  • deflate: invia sempre i messaggi utilizzando la compressione deflate
  • none: invia sempre i messaggi senza compressione

Vedi anche: Apigee supporta la compressione/de-compressione con GZIP/de-compressione?
request.retain.headers.
enabled		 true Per impostazione predefinita, Apigee Edge conserva sempre tutte le intestazioni HTTP nei messaggi in uscita. Se è impostato su true, tutte le intestazioni HTTP presenti nella richiesta in entrata vengono impostate nella 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 passare l'intestazione User-Agent, imposta il valore di request.retain.headers su User-Agent. Più intestazioni HTTP sono specificate come elenco separato da virgole, ad esempio User-Agent,Referer,Accept-Language. Questa proprietà sostituisce request.retain.headers.enabled. Se request.retain.headers.enabled è impostato su false, tutte le intestazioni specificate nella proprietà request.retain.headers vengono comunque impostate nel messaggio in uscita.
response.retain.headers.
enabled		 true Per impostazione predefinita, Apigee Edge conserva sempre tutte le intestazioni HTTP nei messaggi in uscita. Se impostato su true, tutte le intestazioni HTTP presenti nella risposta in entrata dal servizio di destinazione vengono impostate nella risposta in uscita prima di essere passata a ProxyEndpoint.
response.retain.headers N/A Definisce intestazioni HTTP specifiche della risposta che devono essere impostate nella risposta in uscita prima di essere trasmesse a ProxyEndpoint. Ad esempio, per passare l'intestazione Expires, imposta il valore di response.retain.headers su Expires. Più intestazioni HTTP sono specificate come elenco separato da virgole, ad esempio, Expires,Set-Cookie. Questa proprietà sostituisce response.retain.headers.enabled. Se response.retain.headers.enabled è impostato su false, tutte le intestazioni specificate nella proprietà response.retain.headers vengono comunque impostate nel messaggio in uscita.
retain.queryparams.
enabled		 true Per impostazione predefinita, Apigee Edge conserva sempre tutti i parametri di query nelle richieste in uscita. Se il criterio è impostato su true, tutti i parametri di query presenti nella richiesta in entrata vengono impostati nella richiesta in uscita verso il servizio di destinazione.
retain.queryparams N/A Definisce parametri di query specifici da impostare nella richiesta in uscita. Ad esempio, per includere il parametro di query apikey dal messaggio della richiesta, imposta retain.queryparams su apikey. Più parametri di query sono specificati come elenco separato da virgole, ad esempio apikey,environment. Questa proprietà sostituisce retain.queryparams.enabled.

Proprietà di trasporto ProxyEndpoint

Gli elementi HTTPTargetConnection ProxyEndpoint definiscono un insieme di proprietà di trasporto HTTP. Queste proprietà possono essere utilizzate per impostare configurazioni a livello di trasporto.

Le proprietà vengono impostate sugli elementi ProxyEndpoint HTTPProxyConnection come segue:

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

Per saperne di più sugli host virtuali, consulta Informazioni sugli host virtuali.

Specifica della proprietà di trasporto ProxyEndpoint

Nome proprietà Valore predefinito Descrizione
X-Forwarded-For false Se è 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.
enabled		 false Per impostazione predefinita (false), i payload delle richieste HTTP vengono letti in un buffer e i criteri in grado di operare sul payload funzionano come previsto. Nei casi in cui i payload siano superiori alla dimensione del buffer (10 MB), 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 richiesta TargetEndpoint. In questo caso, tutti i criteri che operano sul payload nel flusso di richieste ProxyEndpoint vengono ignorati. Vedi anche Richieste e risposte di flussi di dati.
response.streaming.
enabled		 false Per impostazione predefinita (false), i payload delle risposte HTTP vengono letti in un buffer e i criteri in grado di operare sul payload funzionano come previsto. Nei casi in cui i payload siano superiori alla dimensione del buffer (10 MB), puoi impostare questo attributo su true. Quando true, i payload delle risposte HTTP non vengono letti in un buffer, ma vengono trasmessi così come sono al client. In questo caso, tutti i criteri che operano sul payload nel flusso di risposta di ProxyEndpoint vengono ignorati. Vedi anche Richieste e risposte di flussi di dati.
compression.algorithm N/A

Per impostazione predefinita, Apigee Edge rispetta il tipo di compressione impostato per qualsiasi messaggio ricevuto. Ad esempio, se un client invia una richiesta che utilizza la compressione gzip, Apigee Edge inoltra la richiesta al target utilizzando la compressione gzip. Puoi configurare gli algoritmi di compressione da applicare esplicitamente impostando questa proprietà su TargetEndpoint o ProxyEndpoint. I valori supportati sono:

  • gzip: invia sempre i messaggi utilizzando la compressione gzip
  • deflate: invia sempre i messaggi utilizzando la compressione deflate
  • none: invia sempre i messaggi senza compressione

Vedi anche: Apigee supporta la compressione/de-compressione con GZIP/de-compressione?
api.timeout N/A

Configurare il timeout per singoli proxy API

Puoi configurare i proxy API, anche quelli per cui è abilitato il flusso, in modo che scada dopo un periodo di tempo specificato con uno stato 504 Gateway Timeout. Il caso d'uso principale è per i clienti con proxy API che richiedono più tempo per l'esecuzione. Ad esempio, supponiamo che tu abbia bisogno di proxy specifici per il timeout a 3 minuti. Di seguito è riportato come utilizzare api.timeout.

  1. Innanzitutto, assicurati di configurare il bilanciatore del carico, il router e il processore di messaggi in modo che scadano dopo tre minuti.
  2. Quindi, configura i proxy pertinenti in modo che scadano dopo tre minuti. Specifica il valore in millisecondi. Ad esempio: <Property name="api.timeout">180000</Property>
  3. Tuttavia, tieni presente che l'aumento dei timeout di sistema potrebbe causare problemi di prestazioni, poiché tutti i proxy senza un'impostazione api.timeout utilizzano i nuovi timeout più elevati per il bilanciatore del carico, il router e il processore di messaggi. Pertanto, configura altri proxy API che non richiedono timeout più lunghi per utilizzare timeout più bassi. Ad esempio, quanto segue imposta il timeout di un proxy API dopo 1 minuto:
    <Property name="api.timeout">60000</Property>

Non puoi impostare questa proprietà con una variabile.

I clienti che non possono modificare i timeout Edge possono anche configurare un timeout del proxy API, a condizione che sia più breve rispetto al timeout standard del processore di messaggi Edge di 57 secondi.

Consulta Impostazione di io.timeout.millis e api.timeout per Edge per saperne di più.

Impostazione di io.timeout.millis e api.timeout per Edge

Su Edge, il funzionamento di io.timeout.millis e api.timeout è correlato. A ogni richiesta a un proxy API:

  1. Il router invia il suo valore di timeout al processore di messaggi. Il valore di timeout del router corrisponde al valore proxy_read_timeout impostato dall'host virtuale che gestisce la richiesta o al valore di timeout predefinito di 57 secondi.
  2. Il processore di messaggi imposta quindi api.timeout:
    1. Se api.timeout non è impostato a livello di proxy, impostalo sul timeout del router.
    2. Se api.timeout è impostato al livello di proxy, impostalo sul processore di messaggi sul valore di timeout del router minore o sul valore api.timeout.

  3. Il valore api.timeout specifica il tempo massimo di esecuzione di un proxy API dalla richiesta API alla risposta.

    Dopo l'esecuzione di ciascun criterio nel proxy API o prima che il processore di messaggi invii la richiesta all'endpoint di destinazione, calcola (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 504.

  4. Il valore io.timeout.millis specifica il tempo massimo di risposta dell'endpoint di destinazione.

    Prima di connettersi a un endpoint di destinazione, il processore di messaggi determina il valore minore tra (api.timeout - tempo trascorso dall'inizio della richiesta) e io.timeout.millis. Quindi, imposta io.timeout.millis su questo valore.

    • Se si verifica un timeout durante la scrittura della richiesta HTTP, viene restituito 408, Request Timeout.
    • Se si verifica un timeout durante la lettura della risposta HTTP, viene restituito 504, Gateway Timeout.

Informazioni su ScriptTarget per le applicazioni Node.js

L'elemento ScriptTarget viene utilizzato per integrare un'applicazione Node.js nel proxy. Per informazioni sull'utilizzo di Node.js e ScriptTarget, consulta:

Informazioni sugli endpoint HostedTarget

Un tag <HostedTarget/> vuoto indica a Edge di utilizzare come destinazione un'applicazione Node.js di cui viene eseguito il deployment nell'ambiente destinazioni ospitate. Per maggiori dettagli, consulta la Panoramica dei target ospitati.