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

[Piotr Sikora]

Hey Maxim,

> By saying "most popular use case" you are talking about something
> real-world you are aware of?

Yes.

Furthermore, I'm aware of a few systems using NGINX that use either
ugly workarounds or are missing features exactly because NGINX doesn't
support trailers.

> And this probably an additional thing to consider when introducing
> trailers: right now nginx strips all trailers.  Changing this may
> be a surprise for those who use trailers internally, if any.

This can be easily mitigated with "proxy_pass_trailers on|off".

> We've already talked about gRPC.

Yes, and I'm not sure why you keep ignoring it.

If it's because you assume that it has to be end-to-end HTTP/2 and as
such trailers aren't the main blocker, then there are reverse proxies
like grpc-gateway [1] (which, coincidentally, doesn't support
trailers), that convert HTTP/1.1 requests to a "pure" gRPC requests
and back... Lack of trailers in NGINX prevents people from writing
custom upstream gRPC module, which could provide similar functionality
in NGINX.

However, if it's because "it's Google pushing it's own library", then
it's neither good nor technical reason for rejecting trailers support.

[1] https://github.com/grpc-ecosystem/grpc-gateway

> Fetch API and Server Timing are
> just specifications being developed which allow use of trailers,
> not much different from HTTP/1.1 itself.

Well, they wouldn't be adding it if it was so useless, would they?

> On the other hand, here is a good discussion of trailers and their
> security in this Fetch API ticket:
>
> https://github.com/whatwg/fetch/issues/34

Yes, and the consensus is that there are no new security implications,
as long as you don't magically merge trailers with headers (which, as
previously stated, I have no intention of doing).

> And here is a linked HTTPbis ticket to reconsider "TE: trailers"
> as it looks unneded:
>
> https://github.com/httpwg/http11bis/issues/18
>
> This is somewhat in line with what I think about it, as previously
> discussed in this thread.

I can drop this requirement if you insist, but that's much less
conservative approach than NGINX usually takes and I expect that some
obscure HTTP clients will break because of lack of proper support for
trailer-part in chunked encoding.

> I'm still not convinced that trailers are needed.  As previously
> said, this HTTP feature was mostly unused for 17 years, and
> this suggests something is wrong with the feature.  So it may be a
> good idea to postpone this at least till some real user will
> appear.

You have real users commenting in this thread, why do you keep
ignoring them? Other people already expressed interest, commented on
their internal implementations and/or said that they use workarounds
because NGINX doesn't support trailers.

What more do you need?

> In either case, I do not think that added trailers should by
> itself change transfer encoding used and remove Content-Length.

Again, why this is an issue with trailers but it's not an issue with gzip?

Best regards,
Piotr Sikora