curl -N no pot dir a un proxy que aturi el buffering
Localitzeu el buffering al costat del client, de l'intermediari o de la representacio, sense suposar que l'opcio de sortida de curl canvia tot el cami de resposta.
curl -N, o --no-buffer, desactiva el buffering del flux de sortida de curl. Pot ajudar a diagnosticar una sortida endarrerida sense canviar la politica de buffering del proxy ni del servidor.
curl --proxy http://proxy.example:8080 --noproxy '' --no-buffer --max-time 30 https://example.com/streamPer a una comparacio amb un proxy public, trieu un extrem HTTP de la llista de proxys HTTP. Feu servir la vostra URL real de flux i trieu el limit previst. La llista de bypass buida manté aquesta comparacio a la ruta del proxy seleccionat.
Arribada, descodificacio i visualitzacio
Un servidor pot generar bytes incrementals, un intermediari pot recollir-los, una biblioteca client pot llegir el cos complet i un navegador pot ajornar la representacio. Compareu els primers bytes utils i el progres posterior alla on controleu el cami. El temps de pintat i la durada total del servidor no identifiquen quan arriba el cos.
A Guzzle, comproveu l'streaming i el consum del cos per separat. La compressio afegeix una etapa de descodificacio. Un canvi en el moment en que apareix la sortida descodificada no identifica per si sol un proxy com el component de buffering.
Que veu l'intermediari
Un proxy CONNECT opac no pot analitzar les respostes HTTPS internes com a HTTP ordinari. Un servei d'inspeccio TLS autoritzat te una visibilitat diferent, aixi que HTTPS per si sol no demostra l'absencia d'inspeccio.
Un cop identificada l'etapa d'espera, feu servir els controls d'streaming que admet aquell component. Les directives de proxy invers no s'apliquen automaticament a un proxy directe; l'opcio de sortida de curl nomes canvia la seva propia part del cami.