#http #browser #tcp #timeout #connection-timeout
Вопрос:
Существуют аналогичные вопросы по управлению длительными HTTP-запросами, но цель состоит в том, чтобы избежать потоковой передачи или фрагментированного кодирования.
Причина в том, чтобы упростить работу пользователя API, когда он делает запрос API и получает в ответ файл изображения-нет необходимости повторно собирать фрагментированные/потоковые данные.
Основываясь на сообщениях в других местах, отправка заголовков ответов немедленно, до того, как тело будет готово, сохранит связь.
Фрагментированное кодирование позволяет это сделать, но это требует от пользователя дополнительной работы по повторной сборке фрагментированных/потоковых данных.
Можно ли отправить одно свойство заголовка ответа обратно, а затем отправить остальные заголовки, когда тело будет готово?
Комментарии:
1. Возможно ли это — конечно. Помогает ли это — может быть, а может быть, и нет, может быть, для одних и не для других. В стандарте HTTP нет понятия длительных ответов, речь идет о запросе и следующем ответе. Это не меняется при фрагментированном кодировании, которое связано только с незнанием длины заранее, но не с задержкой ответа. Учитывая, что поведение не стандартизировано, результат будет зависеть от конкретных реализаций.
2. @SteffenUllrich спасибо. не могли бы вы любезно опубликовать ответ о том, как вы могли бы сначала вернуть один заголовок ответа, а затем вернуть остальные заголовки и текст позже (на любом языке, который вам наиболее удобен)?
3. Как это сделать, полностью зависит от реализации сервера, и об этом ничего не известно. Предполагая, что у вас есть полный контроль над сокетом TCP, просто отправьте первые заголовки в соответствии со стандартом HTTP. Если у вас нет полного контроля над сокетом, то это может быть или не быть возможным с тем, что у вас есть в качестве серверной реализации.