H2o: дополнительная поддержка для потоковой передачи запросов

Кто-нибудь работает или заинтересован в этом запросе функции? Как мы можем помочь найти заинтересованных лиц для внедрения?

Меня интересует часть http1, но я не совсем понимаю, как реализовать эту функцию.

@kazuho Меня интересует мруби, хотя я не знаю, с чего начать. :)

Я также предполагаю, что имеет смысл начать работать над этим, как только # 1966 будет объединен, не так ли?

@kazuho есть какие-нибудь

https://github.com/h2o/h2o/pull/1357 было бы хорошим началом, поскольку в нем реализована потоковая передача запросов для http2 и обработчика прокси.

Ключевой частью является то, что он заставляет обработчики (mruby, fastcgi, proxy, ...) объявлять, поддерживают ли они потоковую передачу через h2o_handler_t::has_body_stream . Если это так, запросы, полученные через http2 (поскольку потоковая передача для http1 пока отсутствует), могут быть переданы через следующие элементы структуры h2o_req_t:

    struct {
        h2o_write_req_chunk cb;
        void *priv;
    } _write_req_chunk;
    h2o_write_req_chunk_done _write_req_chunk_done;

Понятно, спасибо @deweerdt. И как это отразится на стороне Мруби? (т.е. как бы вы инициировали обратный вызов или уведомление, чтобы получить новые фрагменты из потока данных)

Для mruby это будет означать настройку обратного вызова блока записи, чтобы протокол внешнего интерфейса (в настоящее время только http2) мог записывать блоки тела, когда они становятся доступными. Вот где это делает прокси: https://github.com/h2o/h2o/blob/master/lib/core/proxy.c#L632

Извините, ребята ... на самом деле у меня была реализация потоковой передачи запросов mruby, которая почти завершена, но не продвигалась в течение долгого времени. Я зарегистрировал незавершенную работу по связям с общественностью как №1980.

@tomas, если вы заинтересованы в его реализации, мы будем признательны, если вы будете работать на этой ветке и не стесняйтесь спрашивать меня о чем угодно. Если вместо этого вы просто хотите использовать его, подождите еще немного.

Отличные новости @ i110! Могу помочь с тестированием, если это поможет. Я работаю над потоковым составным парсером и хотел бы попробовать его с вашей веткой.

Судя по тому, что я вижу в вашем PR, все должно работать как есть, верно? (По крайней мере, для получения, а не для отправки данных)

Я вижу, что некоторая работа для потоковой передачи запросов http 1 находится в https://github.com/h2o/h2o/pull/2007. Может кто-нибудь уточнить, ожидается ли теперь, что она будет работать на HTTP 1.1?

Я изменил пример POST чтобы использовать потоковый API, но он работает только для запросов HTTP 2.

Когда я заставляю CURL использовать HTTP 1.1, req->write_req.cb вообще не вызывается, даже если req->proceed_req не равно NULL, частичный ответ доступен в req->entity и я инициализирую обратные вызовы должным образом:

https://gist.github.com/kishorenc/9aa7073fd31e10b5bcc4ceec9682cd0e#file -h2o_streaming-cpp-L61-L77

Будем очень признательны за быстрое разъяснение.

@kazuho @deweerdt Извините, что снова натолкнул эту не работает на HTTP 1.1, но работает для HTTP 2 - не могли бы вы подтвердить статус поддержки потоковой передачи запросов для HTTP 1.1? Спасибо.

@kishorenc вызывает ли req-> continue_req помощь вручную?

Это сработало @chenbd - трюк был в том, чтобы вызвать req->process_req вручную. Я убедился, что потоковая передача тела запроса теперь работает как для http 1.1, так и для http 2.

Очень благодарен за вашу помощь здесь. Спасибо.

@chenbd или другие, у меня здесь следующий вопрос: желаемое поведение заключается в том, чтобы следующий фрагмент тела запроса отправлялся в обратный вызов только при вызове req->process_req . Однако в HTTP 2 обратные вызовы асинхронных запросов запускаются последовательно даже до вызова req->process_req - это нежелательно, потому что мое приложение не завершает обработку предыдущего фрагмента до прибытия следующего фрагмента.

Почему существует разница в поведении HTTP 1.1 и HTTP 2? Является ли поведение HTTP 2 ошибкой?

Обнаружена проблема: http2.active_stream_window_size превышает размер тела запроса. В HTTP2 обратный вызов тела запроса вызывается несколько раз с фрагментами по 16384 байтов, пока не будет достигнут размер active_stream_window_size . Однако в HTTP 1 обработчик вызывается только один раз с небольшим размером блока и требует вызова process_req() для выборки следующих блоков.