transfer-encoding: chunked

Смотря какой клиент и какой сервер. Если клиент - браузер, то сомневаюсь.

положим клиент и сервер мои, оба на golang

Если всё твоё - то делать можно что угодно. Ведь в твоём коде нет никаких ограничений на функционал.

больше похоже на http/2

Чем?

я хочу чтобы это соответствовало http

Очевидный HTTP/1.1 и выше, с использованием 2-х пар запрос-ответ.

двух пар? это как?

Типа в первый раз делаем post с пустым телом и получаем данные, а второй раз post и инфой? это норм для http в одном соединении?

Потому 1.1 и выше - там подключение не закрывается по умолчанию после ответа.
А так да, что-то вроде такого:

Запрос 1:

GET /api/fetch HTTP/1.1
Host: www.example.org

HTTP/1.1 200 OK
Content-Type: application/x-myproto+json
Content-Length: 20

{ "field": "value" }

POST /api/report HTTP/1.1
Host: www.example.org
Content-Type: application/x-myproto+json
Content-Length: 20

{ "field": "value" }

HTTP/1.1 200 OK
Content-Length: 0

http/2 работает со стримами, которые можно держать открытыми сколько нужно и гонять по ним данные в обе стороны

Зачем тебе чему-то соответствовать, если обе стороны софта твои? Если же расчёт на то, что какая-то сторона может стать чужой - надо смотреть именно проблемы совместимости с тем что там будет, а не абстрактные спецификации непонятно зачем.

у меня условно 99 методов rest/http, а один вот такой странный, соответственно либо его оставлять http либо сбоку вкручивать ws и тд. так что радостно что это в стандарте

спасибо! опишу его в swagger как post)

То, что ТС описал, вполне достигается на HTTP 1.1.

ну с помощью приседаний - да, а на http/2 достигается тупо в лоб, он для того и был сделан

Без приседаний всё делается, окстись.

таки да, перечитал изначальный пост, почему-то думал, что вторую посылку данных должен был инициировать сервер

Можно ли используя subj получить следующий кейс:

chunked не имеет отношение к такой асинхронной модели общения. Ближайшее похожее — это HTTP/1.1 pipelining, когда можно попытаться отправить следующий запрос, не дожидаясь окончания ответа на текущий, но это явно не твой случай.

keep-alive может показаться годным решением (послали первый запрос, получили ответ, ждем 20 секунд, посылаем второй запрос, вычитываем ответ на него), но reverse-proxy между клиентом и сервером легко поломает эту схему.

Единственное, что более-менее похоже и может работать в теории — expect 100-continue. Проблема в том, reverse proxy также может ломать эту штуку. Мне почему-то вспоминается, что когда-то nginx самостоятельно отсылал 100-continue ответ клиенту. Ну и данные, передаваемые сервером, придется запихать в заголовки первого ответа.

Соединяешься, делаешь GET-запрос, с connection keepalive заголовком. Сервер не разрывает соединение. Через 20 секунд делаешь POST-запрос и закрываешь соединение.

Сервер не обязан уважать заголовок keepalive, также это не обязаны уважать промежуточные прокси, но если ты контролируешь всю инфраструктуру, то работать оно будет именно так.

Chunked тут не при чём. Chunked это когда сторона, посылающая даныне, не знает заранее их длину.

А вообще не очень понятно, зачем тебе заострять внимание на том, что соединение не должно разрываться на эти 20 секунд. Скорей всего ты что-то делаешь не так. Оно может и не будет разрываться, но для твоего кода это не должно иметь значения.

положим клиент и сервер мои, оба на golang

В этом случае возможно всё описанное и даже просто что угодно не по стандарту.

Chunked тут не при чём. Chunked это когда сторона, посылающая даныне, не знает заранее их длину.

+1

А вообще не очень понятно, зачем тебе заострять внимание на том, что соединение не должно разрываться на эти 20 секунд. Скорей всего ты что-то делаешь не так. Оно может и не будет разрываться, но для твоего кода это не должно иметь значения.

Всмысле не так. Чел просто делает свой вебсокет внутри обычного HTTP.