HTTP2 DATA frames with 0 length

[Muhui Jiang]

Hi Valentin

Thanks for your email.

if it sees the end of buffer chain in nginx, it adds the END_STREAM flag
========================
Here the buffer chain means the ssl buffer?

The thing I am curious is that why nginx need to carry a data frame whose
payload length is zero. Nginx could add the END_STREAM flag in the previous
DATA frame.
Since I am doing some research work using nginx. I hope that the nginx only
return one DATA frame to me when I request an object. However, No matter
how small the object size is, nginx will always add an extra DATA frame
whose length is zero plus an END_STREAM flag. Do you have any suggestions
or could you please propose a configuration that NGINX will only return one
DATA frame for one stream. Many thanks

Regards
Muhui

2017-09-02 4:32 GMT+08:00 Valentin V. Bartenev <vbart at nginx.com>:

> On пятница, 1 сентября 2017 г. 19:59:04 MSK Muhui Jiang wrote:
> > Hi
> >
> > I am using nginx 1.9.15. I noticed when I made a HTTP2 request to the
> > nginx. It will send the data frames that carry the object first. But end
> > with a data frame whose length is zero indicating the Data end flag.
> >
> > I am curious why you guys design in this way. I think we don't need this
> > extra data frame. Maybe nginx has already fix this, If so, could you tell
> > me the exact version.. Many Thanks
> >
>
> Request processing in nginx is quite complex.  There may have many data
> sources, modules, filter modules, and so on.  The HTTP/2 module works quite
> straightforward, if it sees the end of buffer chain in nginx, it adds the
> END_STREAM flag.  Otherwise, it doesn't.
>
> So, whether you see END_STREAM in a separate DATA frame or not depends on
> many factors and your configuration.
>
>   wbr, Valentin V. Bartenev
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170902/a10e8d70/attachment.html>