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/

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel