Я подозреваю, что реальной точкой блокировки является шлюз (веб-сервер), а не приложение CGI. Шлюз технически должен проверять ответ и убедиться, что он соответствует версии HTTP, которую шлюз использует с клиентом.
Я не уверен, что шлюзу даже разрешено пересылать заголовки до тех пор, пока все запросы не будут обработаны. Если вы посмотрите на CGI specification в разделе 3.1 «Обязанность сервера», вы можете прочитать следующее:
сервера должен выполнять переводы и преобразование протоколов по данным запроса клиента, необходимых в данной спецификации. Кроме того, сервер несет ответственность перед клиентом, чтобы он соответствовал соответствующему сетевому протоколу, даже если сценарий CGI не соответствует этой спецификации.
Если сценарий занимает много времени, и вы хотите периодические обновления, вам гораздо лучше пересмотреть свою архитектуру. Взгляните на более классические стратегии для этого подхода, в основном имея сценарий, выполняемый в фоновом процессе, который записывает в базу данных и записывает некоторый код AJAX для извлечения уведомлений с сервера. В зависимости от того, что вы используете в качестве стека серверов, вы также можете написать приложение для связи через web socket, что позволит вам поддерживать непрерывное соединение и отправлять обновления, когда захотите.
Что вы хотите, чтобы использовать веб-сервер? Для прогрессивного ответа требуется сервер с поддержкой HTTP/1.11 с возможностью кодирования с кодировкой. – SingleNegationElimination
Я думаю @TokenMacGuy прав. Вероятно, происходит то, что ваш выход буферизуется. – jcollado