Com tracta un servidor intermediari directe una capçalera API personalitzada

Una API pot portar la seva versió en un camp de petició personalitzat com ara API-Version. Un servidor intermediari directe ordinari no hauria de descartar aquest camp només perquè el nom no li resulta familiar. HTTP exigeix reenviar els camps no reconeguts tret que s’apliqui una excepció definida o una política configurada.

El camp Connection és una d’aquestes excepcions. Compareu aquestes peticions il·lustratives:

API-Version: 2026-10
Connection: keep-alive

Aquí el camp de l’API no s’ha designat com a local d’aquesta connexió. En l’exemple següent, el remitent en canvia explícitament l’abast:

API-Version: 2026-10
Connection: API-Version

Un servidor intermediari directe elimina els camps que anomena Connection abans de reenviar-los i elimina o substitueix les mateixes instruccions específiques de la connexió. Per tant, una capçalera d’aplicació destinada a l’origen no hauria d’aparèixer en aquesta llista de testimonis.

Trobeu el punt on canvia el camp

Compareu la petició construïda pel client, els camps que rep i reenvia el servidor intermediari, i què ha rebut l’origen. Un client pot ometre una capçalera abans que el servidor intermediari la vegi; un filtre configurat pot eliminar-la deliberadament; un servidor pot rebutjar una petició per haver superat un límit de capçaleres.

No deduïu una eliminació silenciosa només a partir d’un llindar de mida de capçalera informat en un desplegament antic. Els límits i el comportament de rebuig pertanyen als components i a la configuració reals. Conserveu la resposta HTTP i els registres rellevants amb l’observació.

Per a HTTPS d’extrem a extrem dins d’un túnel CONNECT ordinari, el servidor intermediari no pot llegir ni eliminar selectivament el camp intern de l’API. La inspecció de capçaleres correspon llavors als extrems TLS o a un intermediari d’inspecció explícitament de confiança.