curl -N kan ikkje be ein proxy om å slutte å bufre
Finn ut kvar bufferinga ligg - på klient-, mellomledd- eller attgjevingssida - utan å anta at utdataflagget til curl endrar heile svarvegen.
curl -N, eller --no-buffer, slår av bufferinga av utdatastraumen til curl. Det kan hjelpe med å diagnostisere forseinka utdata utan å endre bufferpolitikken til proxyen eller serveren.
curl --proxy http://proxy.example:8080 --noproxy '' --no-buffer --max-time 30 https://example.com/streamFor ei samanlikning via ein offentleg proxy, vel eit HTTP-endepunkt frå HTTP-proxyoversikta. Bruk den faktiske straum-URL-en din og vel den tiltenkte grensa. Den tomme omgåingslista held denne samanlikninga på den valde proxy-ruta.
Kome, dekoding og vising
Ein server kan generere trinnvise byte, eit mellomledd kan samle dei, eit klientbibliotek kan lese heile kroppen, og ein nettlesar kan utsetje attgjevinga. Samanlikn dei første nyttige byta og den vidare framdrifta der du kontrollerer ruta. Malingstid og total varigheit til serveren identifiserer ikkje når kroppen kjem.
I Guzzle, sjekk strauming og kroppsforbruk separat. Komprimering legg til eit dekodingstrinn. Ei endring i når dekoda utdata viser seg, beviser ikkje i seg sjølv at ein proxy er bufferkomponenten.
Kva mellomleddet ser
Ein ugjennomsiktig CONNECT-proxy kan ikkje parse indre HTTPS-svar som vanleg HTTP. Ein autorisert TLS-inspeksjonsteneste har ei anna synlegheit, så HTTPS åleine beviser ikkje at det ikkje blir inspisert.
Når ventetrinnet er identifisert, bruk straumekontrollane som komponenten støttar. Reglar for omvend proxy gjeld ikkje automatisk for ein framoverproxy; utdataflagget til curl endrar berre sin eigen del av ruta.