Speaking of trailers: we had couple of use cases for HTTP trailers, most of them were around streaming data to user.
For example, when webpage is generated we send headers and part of the body(usually up to `</head>`) almost immediately, but then we start querying all the micro services for the content (SOA, yay!). The problem is that upstreams will inevitably fail/timeout, and when that happens there is no way to pass any metadata about the error to nginx, since headers are already sent. Using trailers here may improve MTTR since backend metadata is available on the frontend. Another example may be computing checksums for data while you stream it and putting it in the trailer. This should reduce TTFB by quite a lot on some workloads we have. > On Jul 13, 2016, at 5:34 PM, Piotr Sikora <[email protected]> wrote: > > Hey Maxim, > >> 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. > > Let's step back a bit... I have no plans to change the processing > logic nor merge trailers with headers. Trailers are going to be > ignored (passed, but not processed) by NGINX, not discarded. > > AFAIK, Apache does the same thing. > > Basically, at this point, trailers act as metadata for the application > (browser, gRPC, 3rd-party NGINX module, etc.), with no HTTP semantics, > so there are no security implications for NGINX itself. > > Best regards, > Piotr Sikora > > _______________________________________________ > nginx-devel mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-devel
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
