[PATCH 1 of 2] HTTP: add support for trailers in HTTP responses

[Maxim Dounin]

Hello!

On Wed, Jul 06, 2016 at 02:02:19PM -0700, Piotr Sikora wrote:

> Hey Maxim,
> 
> > I'm not convinced this feature is needed at all.  It looks more
> > like a Google-specific experiment, and this is not something I
> > would like to see in nginx code.
> 
> Wait, what? Are you talking about trailers as defined in RFC7230 (and
> previously in RFC2616 from 1999, when Google barely existed)? There is
> nothing Google-specific about them.
> 
> Also, you had people from 3 different companies asking and/or
> commenting about trailers on this very mailing list in the last 6
> weeks, I'm not sure why you chose to ignore that.

And these 3 people are the only people asking/commenting about 
trailers during the whole nginx history, AFAIR.  And none of them 
provided any real-world use for trailers.  On the other hand, your 
motivation is quite clear, it's about Google pushing it's own 
library, nothing more.

> > If at all implemented, I would rather prefer adding trailers if a
> > transfer encoding used allows this, and discrading them otherwise.
> > This is something that anyway will happen if a protocol used does
> > not allow trailers at all (e.g., HTTP/1.0).
> 
> I'm confused, this is exactly what my patch is doing... unless you
> want to completely ignore "TE" request header?

Your patch forces use of chunked transfer encoding, and that's the 
point where I disagree.  The "TE: trailers" request header means 
that client is able to understand trailers, but it doesn't mean 
that chunked encoding must be used even if content length is 
known.  Using chunked transfer encoding instead of Content-Length 
may or may not be justified by trailers, and this depends on a 
particular use case.

-- 
Maxim Dounin
http://nginx.org/