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.

> 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?

Just keep in mind that per RFC7230, sec. 4.1.2:

Unless the request includes a TE header field indicating "trailers"
is acceptable, as described in Section 4.3, a server SHOULD NOT
generate trailer fields that it believes are necessary for the user
agent to receive. Without a TE containing "trailers", the server
ought to assume that the trailer fields might be silently discarded
along the path to the user agent. This requirement allows
intermediaries to forward a de-chunked message to an HTTP/1.0
recipient without buffering the entire response.

and sec. 4.3:

The presence of the keyword "trailers" indicates that the client is
willing to accept trailer fields in a chunked transfer coding, as
defined in Section 4.1.2, on behalf of itself and any downstream
clients.

Best regards,
Piotr Sikora

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