В общем, это невозможно.Некоторые клиенты заботятся только о заголовке ответа и могут перестать обращать внимание на то, что вы отправляете после заголовка.
Но с некоторыми клиентами в некоторых случаях это может быть возможно.
Я предполагаю HTTP / 1.1 здесь. HTTP / 2 , вероятно, дает еще больше возможностей, потому что в протоколе есть и другие проблемы, а реализации часто строже.И наоборот, HTTP / 1.0 тупее и слабее, поэтому его сложнее сломать.
Закройте соединение до конца ответа, как указано в обрамлении .Если ваш ответ обрамлен Content-Length: 100, закройте, прежде чем вы отправите сотый байт полезной нагрузки.Если ваш ответ помечен Transfer-Encoding: chunked, закройте, прежде чем отправлять последний пустой кусок.Если клиент ожидает получить всю полезную нагрузку, он может ( и ) воспринимать это как ошибку.Но некоторые не будут, включая очень популярные клиентские библиотеки .
Если полезная нагрузка имеет структурированный формат, такой как JSON или XML, то сделайте то же самое, что и 1, но перед закрытием отправьте что-нибудь, что нарушит этот формат.Например, допустимый текст JSON не может заканчиваться {.Даже если клиент не распознает неполную полезную нагрузку как ошибку, он может потерпеть неудачу при попытке ее проанализировать.
То же, что 1, но вместо закрытия соединения просто остановитеотправка данных.Клиент будет «зависать» до тех пор, пока не истечет время его операции приема, что может рассматриваться как ошибка.Это может быть плохой идеей , если клиентом управляет кто-то, кто не готов к таким экстравагантным тайм-аутам.
Только с Transfer-Encoding: chunked: то же, что 3,но вместо того, чтобы висеть, отправляйте поддельные очень длинные куски и / или продолжайте посылать куски бесконечно, пока клиент не сдастся или не выйдет из строя.Вероятно, очень плохая идея , граничащая с вредоносной.