Observeu la petició reenviada d’un proxy a la seva destinació
Trieu el punt d’observació correcte per a les capçaleres que s’afegeixen o es canvien després que el client enviï una petició HTTP.
Un client prepara una petició HTTP, i un proxy directe pot canviar aquest missatge abans d’enviar-lo més enllà. La destinació és on la versió reenviada es fa observable.
| Punt d’observació | Missatge disponible allà |
|---|---|
| Objecte de petició del client | La petició preparada per al primer salt |
| Registre de peticions de l’origen o gestor d’eco | La petició rebuda després del reenviament |
| Col·lecció de capçaleres de resposta del client | La resposta rebuda en el camí de tornada |
Per a una comprovació controlada, feu servir un punt final que gestioneu vosaltres i que enregistri o retorni les capçaleres de petició rebudes. Doneu a la petició un marcador identificable perquè el registre de l’origen es pugui associar a l’operació concreta del client.
En una aplicació basada en WebClient, ResponseHeaders descriu la resposta retornada. No és un registre de la petició del proxy a la destinació. Un servidor pot triar fer eco de la informació de la petició al cos de la resposta, però això és comportament de l’aplicació.
Si el camí conté diversos intermediaris, la destinació veu els seus efectes de reenviament combinats. La mera presència d’una capçalera no atribueix un canvi a un salt concret. Per als camps d’API personalitzats, les regles de reenviament i del camp Connection expliquen quan s’espera una alteració.
Un túnel HTTPS CONNECT ordinari afegeix una altra frontera: la petició HTTP interna va xifrada entre el client i el lloc web. Un proxy de relé no pot editar aquestes capçaleres xifrades. Les capçaleres de l’intercanvi CONNECT pertanyen a aquest intercanvi separat, mentre que un proxy d’inspecció TLS gestionat té un paper diferent.