Riferimento per le proprietà degli endpoint

Questa pagina si applica ad Apigee e Apigee hybrid.

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 della messaggistica e della connessione. Per una copertura completa delle opzioni di configurazione di TargetEndpoint e ProxyEndpoint, consulta il riferimento per la configurazione dei 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 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>

Specifiche della proprietà di trasporto TargetEndpoint

Nome proprietà Valore predefinito Descrizione
allow.post.without.content.length falso Ti consente di inviare richieste POST senza contenuti nel corpo.
allow.put.without.content.length falso Ti consente di inviare richieste PUT senza contenuti nel corpo.
allow.tls.session.resumption true Se i client true (valore predefinito) riutilizzano le sessioni TLS quando effettuano nuove connessioni al target. Imposta false se non vuoi il riutilizzo della sessione TLS. In genere, il riutilizzo della sessione comporta tempi di connessione più brevi, ma alcuni target potrebbero non supportare il riutilizzo della sessione o avere difficoltà con questa operazione.
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 della connessione di destinazione. Apigee restituisce un codice di stato HTTP 503 se si verifica un timeout della connessione. In alcuni casi, quando viene utilizzato LoadBalancer nella definizione di TargetServer e si verifica un timeout, può essere restituito un codice di stato HTTP 504.

ignore.allow.header.for.405

true

Ti consente di ritrasmettere il codice di stato 405 al client. Se attivi il flag, Apigee restituirà il codice di stato 405 anziché 502.

io.timeout.millis 55000

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

  • Se si verifica un timeout durante la lettura della richiesta HTTP dall'ingress, 408 Request Timeout viene sintonizzato di nuovo. 408 Request Timeout non verrà restituito se si verifica un timeout durante la scrittura di una richiesta al target.
  • Se si verifica un timeout durante la scrittura della richiesta HTTP o la lettura della risposta HTTP, viene restituito 504 Gateway Timeout.

Vedi Impostare io.timeout.millis e api.timeout.

supports.http11 true Se il valore è true e il client invia una richiesta 1.1, al target viene inviata anche una richiesta 1.1, altrimenti al target viene inviata la richiesta 1.0.
use.proxy true

Se il file di override Apigee hybrid contiene la configurazione HTTP_PROXY, come descritto in Configurare il proxy in avanti per i proxy API, utilizza questa proprietà per gestire/controllare i proxy che non devono utilizzare la configurazione del proxy.

Se impostato su false, il proxy API salta le configurazioni del proxy HTTP specificate nel file delle sostituzioni ibride di Apigee per le connessioni di destinazione impostate nel proxy.

use.proxy.tunneling true

Se questo valore è impostato su true e le configurazioni proxy sono specificate nel file di override Apigee hybrid come descritto in Configurare il proxy in avanti per i proxy API, le connessioni target sono impostate per 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 falso

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. Se i payload sono più grandi delle dimensioni 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 all'endpoint di destinazione. In questo caso, tutti i criteri che agiscono sul payload nel flusso di richieste TargetEndpoint vengono ignorati. Vedi anche Richieste e risposte con flussi di dati.

response.streaming.enabled falso

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. Se i payload sono più grandi delle dimensioni del buffer (10 MB in Apigee), puoi impostare questo attributo su true. Se true, i payload delle risposte HTTP non vengono letti in un buffer, ma vengono streamizzati così come sono nel flusso di risposta ProxyEndpoint. In questo caso, tutti i criteri che agiscono sul payload nel flusso di risposta TargetEndpoint vengono ignorati. Vedi anche Richieste e risposte con flussi di dati.

success.codes N/D

Per impostazione predefinita, Apigee tratta i codici HTTP 4XX o 5XX come errori e i codici 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 di successo.

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:

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

Se vuoi che solo il codice HTTP 400 venga considerato 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 rispetta il tipo di compressione impostato (gzip, deflate o none) per i messaggi ricevuti. Se la richiesta viene ricevuta dal client utilizzando, ad esempio, la compressione gzip, Apigee la inoltra al target utilizzando la compressione gzip. Se la risposta ricevuta dal target utilizza deflate, Apigee inoltra la risposta al 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 compressione GZIP/deflate?

request.retain.headers.
enabled
true Per impostazione predefinita, Apigee 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 intestazioni HTTP specifiche della richiesta che devono essere impostate sulla richiesta in uscita al servizio di destinazione. Ad esempio, per trasmettere 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, le intestazioni specificate nella proprietà request.retain.headers rimangono impostate sul messaggio in uscita.
response.retain.headers.
enabled
true Per impostazione predefinita, Apigee conserva sempre tutte le intestazioni HTTP nei messaggi in uscita. Se impostato su true, tutte le intestazioni HTTP presenti nella risposta in entrata del servizio di destinazione vengono impostate sulla risposta in uscita prima che venga passata a ProxyEndpoint.
response.retain.headers N/D Definisce intestazioni HTTP specifiche della risposta che devono essere impostate sulla risposta in uscita prima che venga passata a ProxyEndpoint. Ad esempio, per trasmettere 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 sono ancora impostate sul messaggio in uscita.
retain.queryparams.
enabled
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/D Definisce parametri di ricerca specifici da impostare nella 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à vengono 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 arrivo include le intestazioni HTTP inviate dal client. Le intestazioni con nomi corrispondenti al pattern X-Apigee-* vengono rimosse dalle richieste in entrata se un client le invia. Questo pattern di nome è riservato ad Apigee.

Specifica della proprietà di trasporto ProxyEndpoint

Nome proprietà Valore predefinito Descrizione
X-Forwarded-For falso 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 che possono operare sul payload funzionano come previsto. Se i payload sono più grandi del 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 al flusso di richieste TargetEndpoint. In questo caso, tutti i criteri che operano sul payload nel flusso di richieste ProxyEndpoint vengono ignorati. Consulta anche Richieste e risposte con flussi di dati.
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. Se i payload sono più grandi delle dimensioni del buffer (10 MB in Apigee), 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 ProxyEndpoint vengono ignorati. Consulta anche Richieste e risposte con flussi di dati.
compression.algorithm N/D

Per impostazione predefinita, Apigee rispetta il tipo di compressione impostato (gzip, deflate o none) per i messaggi ricevuti. Ad esempio, se un client invia una richiesta che utilizza la compressione gzip, Apigee 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 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 compressione GZIP/deflate?

api.timeout N/D

Configura il timeout per i singoli proxy API (in millisecondi)

Puoi configurare i proxy API, anche quelli con streaming abilitato, in modo che scadano dopo un determinato periodo di tempo con uno stato 504 Gateway Timeout.

Ad esempio, per configurare un proxy in modo che scada dopo 180000 millisecondi (tre minuti), aggiungi la seguente proprietà a HTTPProxyConnection:

<Property name="api.timeout">180000</Property>

Non puoi impostare questa proprietà con una variabile.

Vedi Impostare io.timeout.millis e api.timeout.

HTTPHeader.allowDuplicates N/D

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/D

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 sono correlati. Per ogni richiesta a un proxy API:

  1. Ingress (noto anche come bilanciatore del carico interno) invia il proprio valore di timeout all'processore di messaggi. Il valore predefinito per questo timeout è 300 secondi e non è configurabile.
  2. Il processore di messaggi imposta quindi api.timeout:
    1. Se api.timeout non è impostato a livello di proxy, utilizza il timeout impostato da Ingress.
    2. Se api.timeout è impostato a livello di proxy, impostalo su processore di messaggi sul valore minore del timeout di Ingress o del valore di api.timeout.
  3. Il valore di api.timeout specifica il tempo massimo di esecuzione di un proxy API 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, il processore di messaggi 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 un 504 Gateway Timeout.

  4. Il valore di io.timeout.millis specifica il tempo massimo entro il quale l'endpoint di destinazione deve rispondere.

    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. Imposta quindi io.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.