[PATCH 1 of 2] HTTP: add support for trailers in HTTP responses

[Maxim Dounin]

Hello!

On Wed, Jul 13, 2016 at 10:25:57AM -0700, Piotr Sikora wrote:

> > So the question remains: are there any real-world use cases?  May
> > be someone will be able to provide some.
> 
> It's a chicken-and-egg problem. It's hard to use a feature that's not
> supported by one of the most popular web servers.

The feature was there for years before nginx became popular.  And 
no one prevents it to be used with other servers, including more 
popular ones.  The fact that there are no real-world use cases 
suggests that there is something wrong with the feature.

> > Without real-world use cases I don't think this should be added,
> > as in general trailers is quite external concept to how nginx
> > works and also may have various security implications.
> 
> Just to be clear, are you talking about HTTP/1.1 trailers or trailers
> in general? The patch also includes HTTP/2 trailers and it's not clear
> which one you don't like.

I'm talking about trailers in general (though it's more about 
requests than responses).  Normal request (and response) 
processing in nginx assumes that headers are processed before the 
body, and adding trailers (which are headers "to be added later") 
to the picture are likely to have various security implications.

> > Silently dropping trailers is what anyway happens if the client
> > doesn't support chunked encoding at all (e.g., uses HTTP/1.0).
> > And this is also what happens in your patch if there is no "TE:
> > trailers".
> 
> Yes, but then it happens for a reason (client doesn't support
> trailers) and not "just because".

"Transfer encoding used doesn't allow trailers" looks like a 
reason for me.

> > I think that whether to drop Content-Length and switch to chunked
> > encoding is highly use-case specific question.  In some cases it
> > may be appropriate, in some cases not, and in some cases one may
> > want to add trailers even without "TE: trailers".  So forcing
> > chunked encoding probably should be configured separately.  On the
> > other hand, it's very hard to decide something given there are no
> > real use cases known.
> 
> Why? I don't see anyone making a big deal out of forced chunked
> encoding with "gzip on".

Gzip drops Content-Length because it's not possible to know it in 
advice.  And does so only for some responses, with various 
configuration options available to prevent this happening for 
clients who can't handle it and/or for responses where it is not 
beneficial.

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