curl -N kan ikke bede en proxy om at stoppe buffering
Find ud af, hvor bufferingen ligger - hos klienten, mellemleddet eller gengivelsessiden - uden at antage, at curls outputflag ændrer hele svarstien.
curl -N, eller --no-buffer, deaktiverer curls buffering af outputstrømmen. Det kan hjælpe med at diagnosticere forsinket output uden at ændre proxyens eller serverens bufferpolitik.
curl --proxy http://proxy.example:8080 --noproxy '' --no-buffer --max-time 30 https://example.com/streamTil en sammenligning via offentlig proxy vælges et HTTP-endepunkt fra HTTP-proxyoversigten. Brug din faktiske stream-URL, og vælg den tilsigtede grænse. Den tomme bypass-liste holder denne sammenligning på den valgte proxyrute.
Ankomst, afkodning og visning
En server kan generere trinvise bytes, et mellemled kan samle dem, et klientbibliotek kan læse hele kroppen, og en browser kan udsætte gengivelsen. Sammenlign de første nyttige bytes og den efterfølgende fremdrift, hvor du styrer ruten. Malingstid og serverens samlede varighed identificerer ikke, hvornår kroppen ankommer.
I Guzzle kontrolleres streaming og kropsforbrug separat. Komprimering tilføjer et afkodningstrin. En ændring i, hvornår afkodet output vises, beviser ikke i sig selv, at en proxy er bufferingskomponenten.
Hvad mellemleddet ser
En uigennemsigtig CONNECT-proxy kan ikke parse indre HTTPS-svar som almindelig HTTP. En autoriseret TLS-inspektionstjeneste har en anden synlighed, så HTTPS alene beviser ikke, at der ikke inspiceres.
Når ventetrinnet er identificeret, bruges de streamingkontroller, som komponenten understøtter. Regler for omvendt proxy gælder ikke automatisk for en fremadrettet proxy; curls outputflag ændrer kun dens egen del af ruten.