curl -N kan nie vir 'n proxy sê om buffering te stop nie
Bepaal waar buffering plaasvind - by die kliënt, die tussenlaag of die weergee-kant - sonder om aan te neem dat curl se uitvoervlag die hele responstrajek verander.
curl -N, of --no-buffer, skakel curl se buffering van die uitvoerstroom af. Dit kan help om vertraagde uitvoer te diagnoseer sonder om die proxy of die bediener se bufferbeleid te verander.
curl --proxy http://proxy.example:8080 --noproxy '' --no-buffer --max-time 30 https://example.com/streamVir 'n vergelyking met 'n publieke proxy, kies 'n HTTP-eindpunt uit die HTTP-proksielys. Gebruik jou werklike stroom-URL en kies die beoogde limiet. Die leë omsyferingslys hou hierdie vergelyking op die gekose proxyroete.
Aankoms, dekodering en vertoning
'n Bediener kan inkrementele grepe genereer, 'n tussenlaag kan hulle versamel, 'n kliëntbiblioteek kan die volledige liggaam lees, en 'n blaaier kan die weergawe uitstel. Vergelyk die eerste nuttige grepe en die daaropvolgende vordering waar jy die roete beheer. Verf-tyd en die bediener se totale duur identifiseer nie wanneer die liggaam aankom nie.
Kontroleer in Guzzle stroming en liggaamsverbruik afsonderlik. Kompressie voeg 'n dekoderingsfase by. 'n Verandering in wanneer gedekodeerde uitvoer verskyn, identifiseer nie op sigself 'n proxy as die bufferkomponent nie.
Wat die tussenlaag sien
'n Ondeursigtige CONNECT-proxy kan nie innerlike HTTPS-antwoorde as gewone HTTP ontleed nie. 'n Gemagtigde TLS-inspeksiediens het ander sigbaarheid, dus HTTPS alleen bewys nie die afwesigheid van inspeksie nie.
Sodra die wagfase geïdentifiseer is, gebruik daardie komponent se ondersteunde stromingsbeheermaatreëls. Omgekeerde-proxy-riglyne geld nie outomaties vir 'n vooruit-proxy nie; curl se uitvoervlag verander net sy eie deel van die roete.