Proxyrotasjon på tvers av førespurnader, tilkoplingar og sesjonar
Kontroller kva ein roterande proxeteneste faktisk roterer før du legg til Connection: close på kvar applikasjonsførespurnad.
Ein annan førespurnad gjennom same gateway kan heilt lovleg bruke same offentlege IP. Kontroller kva levetid tenesta brukar for rotasjonen sin:
| Rotasjonseining | Kva som skal samanliknast |
|---|---|
| Førespurnad | Neste applikasjonsoperasjon og den observerte utgangen hans |
| Tilkopling | Om klienten brukte ein kompatibel tilkopling på nytt eller opna ein annan |
| Sesjonen til leverandøren | Det dokumenterte inndataet for klebrig sesjon og levetida |
Connection: close er ikkje ei universell gateway-instruks. For HTTPS inne i CONNECT reiser førespurnadshovudet til nettstaden inne i TLS-en til destinasjonen. Det fortel ikkje den ytre proxyen kva offentleg IP som skal tildelast. Heller ikkje den tilkoplingsspesifikke semantikken til HTTP/1.1 kan førast uendra over i kvar HTTP-versjon eller transport.
Viss ei dokumentert teneste per tilkopling treng ei ny tilkopling, bruk livssykluskontrollen klienten støttar, og rekne med gjentekne kostnader til TCP/TLS-oppsett. Viss rotasjonen følgjer ein leverandørsesjon, kan ny tilkopling behalde både den sesjonen og utgangen hans.
Loggfør førespurnads-ID, endepunkt, relevant sesjonsnøkkel og kjelda som blir observert ved destinasjonen kvar for seg. Å lukke ei tilkopling fastslår berre den livssyklushendinga; verifiser utgangen som er vald for neste operasjon, mot den faktiske rotasjonskontrakten til tenesta.