Riferimento per le proprietà degli endpoint

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

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 una copertura completa della configurazione di TargetEndpoint e ProxyEndpoint, consulta Riferimento per la configurazione dei proxy API.

Proprietà di trasporto di 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à 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>

Specifica della proprietà di trasporto di 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, viene chiusa.
connect.timeout.millis

3000

Timeout della connessione di destinazione. Edge restituisce un codice di stato HTTP 503 se si verifica un timeout della connessione. In alcuni casi, quando LoadBalancer viene utilizzato nella definizione di TargetServer e si verifica un timeout, potrebbe essere restituito un codice di stato HTTP 504.

io.timeout.millis 55000

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

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

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 comunicare con il processore di messaggi. Per saperne di più, consulta Configurare il timeout del router.

Per saperne di più, consulta Impostare io.timeout.millis e api.timeout per Edge.
supports.http10 true Se questo valore è true e il client invia una richiesta 1.0, alla destinazione viene inviata anche una richiesta 1.0 richiesta. In caso contrario, alla destinazione viene inviata una richiesta 1.1.
supports.http11 true Se questo valore è true e il client invia una richiesta 1.1, alla destinazione viene inviata anche una richiesta 1.1 alla destinazione viene inviata una richiesta 1.0.
use.proxy true Se impostato su true e le configurazioni del proxy sono specificate in http.properties (solo per i deployment on-premise), le connessioni di destinazione sono impostate per utilizzare il proxy specificato.
use.proxy.tunneling true Se questo valore è impostato su true e le configurazioni del proxy sono specificate in http.properties (solo per i deployment on-premise), le connessioni di destinazione sono 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/D 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 le norme che possono operare sul payload funzionano come previsto. Nei casi in cui i payload sono più grandi della dimensione del buffer (10 MB), puoi impostare questo attributo su true. Se true, i payload delle richieste HTTP non vengono letti in un buffer; vengono trasmessi in streaming così come sono all'endpoint di destinazione. In questo caso, tutte le norme che operano sul payload nel flusso di richieste TargetEndpoint vengono ignorate. Vedi anche Flussi di dati per richieste e risposte.
response.streaming.enabled false

Per impostazione predefinita (false), i payload delle risposte HTTP vengono letti in un buffer e le norme che possono operare sul payload funzionano come previsto. Nei casi in cui i payload sono più grandi della dimensione del buffer (10 MB), puoi impostare questo attributo su true. Se true, i payload delle risposte HTTP non vengono letti in un buffer; vengono trasmessi in streaming così come sono al flusso di risposte ProxyEndpoint. In questo caso, tutte le norme che operano sul payload nel flusso di risposte TargetEndpoint vengono ignorate. Vedi anche Flussi di dati per richieste e risposte.
success.codes N/D

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

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

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

Se vuoi che solo il codice HTTP 400 venga trattato come codice di successo, imposta la proprietà come segue:

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

Se imposti il codice HTTP 400 come unico codice di successo, i codici 1XX, 2XX e 3XX vengono trattati come errori.
compression.algorithm N/D Per impostazione predefinita, Apigee Edge inoltra le richieste alla destinazione 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 alla destinazione utilizzando la compressione gzip. Se la risposta ricevuta dalla destinazione utilizza deflate, Apigee Edge inoltra la risposta a il client utilizzando deflate. I valori supportati sono:
  • gzip: invia sempre il messaggio utilizzando la compressione gzip
  • deflate: invia sempre il messaggio utilizzando la compressione deflate
  • none: invia sempre il messaggio senza compressione

Vedi anche: Apigee supporta la compressione/decompressione con la compressione GZIP/deflate?
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/D Definisce le intestazioni HTTP specifiche della richiesta che devono essere impostate nella richiesta in uscita al servizio di destinazione. Ad esempio, per trasmettere l'User-Agent intestazione, 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 request.retain.headers.enabled è impostato su false, tutte le intestazioni specificate nella request.retain.headers proprietà 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 passate a ProxyEndpoint.
response.retain.headers N/D Definisce le intestazioni HTTP specifiche della risposta che devono essere impostate nella risposta in uscita prima di essere passate a ProxyEndpoint. Ad esempio, per trasmettere l' Expires intestazione, 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 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 impostato su true, tutti i parametri di query presenti nella richiesta in entrata vengono impostati nella richiesta in uscita al servizio di destinazione.
retain.queryparams N/D Definisce i parametri di query specifici da impostare nella richiesta in uscita. Ad esempio, per includere il parametro di query apikey nel messaggio di richiesta, imposta retain.queryparams su apikey. Più parametri di query vengono specificati come elenco separato da virgole, ad esempio apikey,environment. Questa proprietà esegue l'override di retain.queryparams.enabled.

Proprietà di trasporto di ProxyEndpoint

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

Le proprietà vengono impostate sugli elementi HTTPProxyConnection di ProxyEndpoint 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 di 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 le norme che possono operare sul payload funzionano come previsto. Nei casi in cui i payload sono più grandi della dimensione del buffer (10 MB), puoi impostare questo attributo su true. Se true, i payload delle richieste HTTP non vengono letti in un buffer; vengono trasmessi in streaming così come sono al flusso di richieste TargetEndpoint. In questo caso, tutte le norme che operano sul payload nel flusso di richieste ProxyEndpoint vengono ignorate. Vedi anche Flussi di dati per richieste e risposte.
response.streaming.
enabled		 false Per impostazione predefinita (false), i payload delle risposte HTTP vengono letti in un buffer e le norme che possono operare sul payload funzionano come previsto. Nei casi in cui i payload sono più grandi di la dimensione del buffer (10 MB), puoi impostare questo attributo su true. Se true, i payload delle risposte HTTP non vengono letti in un buffer; vengono trasmessi in streaming così come sono al client. In questo caso, tutte le norme che operano sul payload nel ProxyEndpoint response flow vengono ignorate. Vedi anche Flussi di dati per richieste e risposte.
compression.algorithm N/D

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 alla destinazione utilizzando la compressione gzip. Puoi configurare gli algoritmi di compressione da applicare in modo esplicito impostando questa proprietà su TargetEndpoint o ProxyEndpoint. I valori supportati sono:

  • gzip: invia sempre il messaggio utilizzando la compressione gzip
  • deflate: invia sempre il messaggio utilizzando la compressione deflate
  • none: invia sempre il messaggio senza compressione

Vedi anche: Apigee supporta la compressione/decompressione con la compressione GZIP/deflate?
api.timeout N/D

Configurare il timeout per i singoli proxy API

Puoi configurare i proxy API, anche quelli con streaming abilitato, in modo che si verifichi un timeout dopo un periodo di tempo specificato con uno stato 504 Gateway Timeout. Il caso d'uso principale è per i clienti che hanno proxy API che richiedono più tempo per l'esecuzione. Ad esempio, supponiamo che tu voglia che i proxy specifici si verifichi un timeout dopo 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 si verifichi un timeout dopo tre minuti.
  2. Quindi configura i proxy pertinenti in modo che si verifichi un timeout dopo tre minuti. Specifica il valore in millisecondi. Ad esempio: <Property name="api.timeout">180000</Property>
  3. Tieni presente, tuttavia, che l'aumento dei timeout di sistema potrebbe causare problemi di prestazioni, perché tutti i proxy senza un'impostazione api.timeout utilizzano i nuovi timeout più elevati del bilanciatore del carico, router e processore di messaggi. Quindi configura altri proxy API che non richiedono timeout più lunghi per utilizzare timeout inferiori. Ad esempio, il seguente imposta un proxy API in modo che si verifichi un timeout 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 di Edge possono anche configurare un timeout del proxy API, purché il timeout sia inferiore al timeout standard del processore di messaggi di Edge di 57 secondi.

Per saperne di più, consulta Impostare io.timeout.millis e api.timeout per Edge.

Impostare io.timeout.millis e api.timeout per Edge

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

  1. Il router invia il valore del timeout al processore di messaggi. Il valore del timeout del router è il valore di proxy_read_timeout impostato dall'host virtuale che gestisce la richiesta o il valore del 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 a livello di proxy, impostalo sul processore di messaggi sul valore inferiore tra il timeout del router e il valore di api.timeout.

  3. Il valore di api.timeout specifica la quantità massima di tempo che un proxy API ha per l'esecuzione dalla richiesta API alla risposta.

    Dopo l'esecuzione di ogni norma nel proxy API, o prima che il processore di messaggi invii la richiesta all'endpoint di destinazione, il processore di messaggi calcola (api.timeout - tempo trascorso dall'inizio della richiesta). Se il valore è inferiore a zero, la quantità massima di tempo per gestire la richiesta è scaduta e il processore di messaggi restituisce 504.

  4. Il valore di io.timeout.millis specifica la quantità massima di tempo che l'endpoint di destinazione ha per rispondere.

    Prima di connettersi a un endpoint di destinazione, il processore di messaggi determina il valore inferiore 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, 408, Request Timeout viene restituito.
    • Se si verifica un timeout durante la lettura della risposta HTTP, 504, Gateway Timeout viene restituito.

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 è stato eseguito il deployment nell'ambiente Hosted Targets. Per saperne di più, consulta Panoramica di Hosted Targets.