Questa pagina è stata tradotta dall'API Cloud Translation.

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 di messaggistica e connessione. Per una copertura completa delle opzioni di configurazione TargetEndpoint e ProxyEndpoint, consulta 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 le 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	Consente di inviare richieste POST senza contenuti nel corpo.
`allow.put.without.content.length`	falso	Consente di inviare richieste PUT senza contenuti nel corpo.
`allow.tls.session.resumption`	true	Se `true` (impostazione predefinita), i client riutilizzano le sessioni TLS quando stabiliscono nuove connessioni alla destinazione. Imposta `false` se non vuoi riutilizzare la sessione TLS. Il riutilizzo della sessione in genere comporta tempi di connessione più brevi, ma alcuni target potrebbero non supportare il riutilizzo della sessione o avere difficoltà con questa funzionalità.
`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, la connessione 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 `LoadBalancer` viene utilizzato nella definizione TargetServer e si verifica un timeout, potrebbe essere restituito un codice di stato HTTP `504`. Nota:in alcuni casi, Apigee ritenta automaticamente la connessione fino a tre volte. Di conseguenza, il tempo totale di nuovi tentativi potrebbe superare quello configurato per `connect.timeout.millis`.
`ignore.allow.header.for.405`	true	Consente di restituire il codice di stato 405 al client. Se attivi il flag, Apigee restituirà 405 anziché 502 come codice di stato.
`io.timeout.millis`	55000	Se non sono presenti dati da leggere per il numero specificato di millisecondi o se il socket non è pronto per scrivere dati per un numero specificato di millisecondi, la transazione viene considerata come timeout. Se si verifica un timeout durante la lettura della richiesta HTTP dall'ingresso, viene restituito `408 Request Timeout`. `408 Request Timeout` non verrà restituito se si verifica un timeout durante la scrittura di una richiesta nella destinazione. Se si verifica un timeout durante la scrittura della richiesta HTTP o la lettura della risposta HTTP, viene restituito `504 Gateway Timeout`. Vedi Impostazione di io.timeout.millis e api.timeout.
`supports.http11`	true	Se questo valore è `true` e il client invia una richiesta `1.1`, al target viene inviata anche una richiesta `1.1`, altrimenti al target viene inviata una richiesta `1.0`.
`use.proxy`	true	Se il file di override di Apigee Hybrid contiene la configurazione `HTTP_PROXY`, come descritto in Configurare l'inoltro del proxy per i proxy API, utilizza questa proprietà per gestire/controllare quali proxy non devono utilizzare la configurazione proxy. Se impostato su `false`, il proxy API ignorerà le configurazioni del proxy HTTP specificate nel file di override di Apigee Hybrid per le connessioni di destinazione impostate nel proxy.
`use.proxy.tunneling`	true	Se questa opzione è impostata su true e sono specificate configurazioni proxy nel file di override di Apigee Hybrid come descritto in Configurare il proxy di inoltro per i proxy API, 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.
`response.payload. parse.limit`	`10M`	Per impostazione predefinita (`10M`). Utilizza la proprietà `response.payload.parse.limit` per impostare la dimensione massima del payload che può essere elaborato nel flusso di risposta, in megabyte (M). Il limite minimo configurabile è 10 MB e il limite massimo configurabile è 30 MB. Se la proprietà non è impostata, il limite predefinito è 10 M. Vedi anche Dimensioni del payload del messaggio.
`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. Nei casi in cui 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; 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`	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. Nei casi in cui i payload sono più grandi delle dimensioni 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 in streaming così come sono al flusso di risposta `ProxyEndpoint`. In questo caso, vengono ignorate tutte le norme che operano sul payload nel flusso di risposta `TargetEndpoint`. Vedi anche Flussi di dati per richieste e risposte.
`success.codes`	N/D	Per impostazione predefinita, Apigee considera 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` considera come riusciti tutti i codici di risposta HTTP `100`, `200` e `505`. 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 un codice di successo, imposta la proprietà come segue: `<Property name="success.codes">400</Property>` Se imposti il codice HTTP `400` come unico codice di operazione riuscita, 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 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 la compressione deflate, Apigee inoltra la risposta al client utilizzando la compressione deflate. I valori supportati sono: gzip: invia sempre il messaggio utilizzando la compressione gzip deflate:invia sempre il messaggio utilizzando la compressione deflate nessuna:invia sempre il messaggio senza compressione Vedi anche: Apigee supporta la compressione/decompressione con 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 nella 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 vengono 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` vengono comunque impostate nel 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 dal servizio di destinazione vengono impostate nella risposta in uscita prima di essere trasmesse a `ProxyEndpoint`.
`response.retain.headers`	N/D	Definisce intestazioni HTTP specifiche della risposta che devono essere impostate nella risposta in uscita prima di essere trasmesse a `ProxyEndpoint`. Ad esempio, per trasmettere l'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à 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 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 le 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 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 di nome è riservato ad Apigee.

Specifiche 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. Nei casi in cui 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; vengono trasmessi in streaming così come sono al flusso di richieste `TargetEndpoint`. In questo caso, tutte le policy che operano sul payload nel flusso di richieste `ProxyEndpoint` vengono ignorate. Vedi anche Flussi di dati per richieste e risposte.
`request.payload. parse.limit`	`10M`	Per impostazione predefinita (`10M`). Utilizza la proprietà `request.payload.parse.limit` per impostare le dimensioni massime del payload che possono essere elaborate nel flusso di richieste, in megabyte (MB). Il limite minimo configurabile è 10 MB e il limite massimo configurabile è 30 MB. Se la proprietà non è impostata, il limite predefinito è 10 M. Vedi anche Dimensioni del payload del messaggio.
`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 delle dimensioni 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; vengono trasmessi in streaming così come sono al client. In questo caso, vengono ignorate tutte le policy che operano sul payload nel flusso di risposta `ProxyEndpoint`. Vedi anche Flussi di dati per richieste e risposte.
`compression.algorithm`	N/D	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 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 nessuna:invia sempre il messaggio senza compressione Vedi anche: Apigee supporta la compressione/decompressione con GZIP/deflate?
`api.timeout`	N/D	Configura il timeout per i singoli proxy API (in millisecondi) Puoi configurare i proxy API, anche quelli con lo streaming abilitato, in modo che si verifichi il timeout dopo un periodo di tempo specificato con uno stato `504 Gateway Timeout`. Importante: il timeout specificato deve essere inferiore al timeout standard del processore di messaggi di 300 secondi. Ad esempio, per configurare un proxy in modo che scada dopo 180.000 millisecondi (tre minuti), aggiungi la seguente proprietà a `HTTPProxyConnection`: <Property name="api.timeout">180000</Property> Non puoi impostare questa proprietà con una variabile. Vedi Impostazione di 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:

L'ingresso (ovvero il bilanciatore del carico interno) invia il valore di timeout al processore di messaggi. Il valore di timeout predefinito è 300 secondi e non è configurabile.
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 sul processore di messaggi sul valore minore tra il timeout di Ingress e il valore di api.timeout.
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 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.
Il valore di io.timeout.millis specifica il tempo massimo di risposta dell'endpoint di destinazione.

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

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