[PATCH] HTTP: add support for trailers in HTTP responses

[Piotr Sikora]

Hey Maxim,

> I still don't see any real world usage example reported.

That's because you chose to ignore those provided to you.

1) As of right now, trailers are ignored by the browsers, so there is
no point in "leaking" them to the public Internet. And indeed, the
most popular use case for trailers is within complex systems, where
trailers are used for logging, tracing, debug messages & signaling
end-of-response... those are usually stripped at the proxies facing
public Internet.

2) You're asking for real world examples of trailers on a mailing list
dedicated to NGINX development, which means that noone here uses
trailers in production, unless they maintain their own version of
NGINX... and yet, you had 4 people (out of a few hundred?) expressing
interest in this feature.

3) Trailers are used in gRPC [1], Fetch API [2] and Server Timing [3],
but I guess none of those is "real world" enough for you.

> Additionally, quick look suggests that the patch still
> unconditionally removes Content-Length from a response if client
> advertizes trailers support.  As I previously wrote, I found this
> approach to be wrong.

Yes, the only change in the patch I sent yesterday is a bugfix to
avoid sending empty DATA frame in case when trailers were generated
but there was no payload to send.

Like I said before, I'm happy to add "r->expect_trailers" or whatever
else mechanism you choose to signal that NGINX is configured to
produce trailers, but if you don't want to add trailers in the first
place, then there is no point in me spending time working on that...
is there?

[1] http://www.grpc.io/docs/guides/wire.html
[2] https://github.com/whatwg/fetch/pull/344
[3] https://www.w3.org/TR/server-timing/

Best regards,
Piotr Sikora