curl -N non può dire a un proxy di smettere di bufferizzare
Individuate dove avviene il buffering - lato client, intermediario o rendering - senza dare per scontato che l'opzione di output di curl cambi l'intero percorso della risposta.
curl -N, o --no-buffer, disattiva il buffering del flusso di output di curl. Può aiutare a diagnosticare un output ritardato senza modificare la politica di buffering del proxy o del server.
curl --proxy http://proxy.example:8080 --noproxy '' --no-buffer --max-time 30 https://example.com/streamPer un confronto tramite un proxy pubblico, scegliete un endpoint HTTP dalla lista dei proxy HTTP. Usate l'URL reale del vostro flusso e scegliete il limite previsto. L'elenco di bypass vuoto mantiene questo confronto sul percorso del proxy selezionato.
Arrivo, decodifica e visualizzazione
Un server può generare byte incrementali, un intermediario può raccoglierli, una libreria client può leggere il corpo completo e un browser può rinviare il rendering. Confrontate i primi byte utili e il progresso successivo dove controllate il percorso. Il tempo di pittura e la durata totale del server non identificano quando arriva il corpo.
In Guzzle, verificate lo streaming e il consumo del corpo separatamente. La compressione aggiunge una fase di decodifica. Un cambiamento nel momento in cui appare l'output decodificato non identifica di per sé un proxy come componente di buffering.
Cosa vede l'intermediario
Un proxy CONNECT opaco non può analizzare le risposte HTTPS interne come HTTP ordinario. Un servizio di ispezione TLS autorizzato ha una visibilità diversa, quindi HTTPS da solo non dimostra l'assenza di ispezione.
Una volta identificata la fase di attesa, usate i controlli di streaming supportati da quel componente. Le direttive del reverse proxy non si applicano automaticamente a un forward proxy; l'opzione di output di curl cambia solo la sua parte del percorso.