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
