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

[Maxim Dounin]

Hello!

On Mon, Aug 01, 2016 at 10:56:21AM -0700, Piotr Sikora wrote:

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

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

> those are usually stripped at the proxies facing public Internet.

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.

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

In my practice, "expressing interest" generally means something 
close to nothing.

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

We've already talked about gRPC.  Fetch API and Server Timing are 
just specifications being developed which allow use of trailers, 
not much different from HTTP/1.1 itself.

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

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.

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

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.

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

-- 
Maxim Dounin
http://nginx.org/