curl -N kan ikke fortelle en proxy at den skal slutte å bufre
Finn ut hvor bufferingen skjer - på klient-, mellomledds- eller gjengivelsessiden - uten å anta at utdataflagget til curl endrer hele svarveien.
curl -N, eller --no-buffer, deaktiverer buffering av curls utdatastrøm. Det kan hjelpe med å diagnostisere forsinket utdata uten å endre bufferpolitikken til proxyen eller serveren.
curl --proxy http://proxy.example:8080 --noproxy '' --no-buffer --max-time 30 https://example.com/streamFor sammenligning via en offentlig proxy, velg et HTTP-endepunkt fra HTTP-proxyoversikten. Bruk den faktiske strømme-URL-en din og velg den tiltenkte grensen. Den tomme omgåelseslisten holder denne sammenligningen på den valgte proxy-ruten.
Ankomst, dekoding og visning
En server kan generere trinnvise byte, et mellomledd kan samle dem, et klientbibliotek kan lese hele kroppen, og en nettleser kan utsette gjengivelsen. Sammenlign de første nyttige bytene og den videre fremdriften der du kontrollerer ruten. Malingstid og serverens totale varighet identifiserer ikke når kroppen ankommer.
I Guzzle, sjekk strømming og kroppsforbruk separat. Komprimering legger til et dekodingstrinn. En endring i når dekodet utdata vises, beviser ikke i seg selv at en proxy er bufferkomponenten.
Hva mellomleddet ser
En ugjennomsiktig CONNECT-proxy kan ikke parse indre HTTPS-svar som vanlig HTTP. En autorisert TLS-inspeksjonstjeneste har en annen synlighet, så HTTPS alene beviser ikke at det ikke inspiseres.
Når ventetrinnet er identifisert, bruk strømmekontrollene som komponenten støtter. Retningslinjer for omvendt proxy gjelder ikke automatisk for en videresendende proxy; curls utdataflagg endrer bare sin egen del av ruten.