Hello! On Thu, Aug 18, 2016 at 06:12:46PM -0700, Piotr Sikora wrote:
> > 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. Could you please describe one of the uses cases in details? That's what I'm asking all the time, and still didn't get even a single description of a real-world use case. > > 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". Sure. This is just one item from the long list of various implications of trailers. > > 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. The last sentense here contradicts the first one. If grpc-gateway is fine without trailers support, I don't see how lack of trailers in nginx prevents one from providing 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? The same applies to HTTP/1.1. Yet trailers are (mostly?) unused for many years. Moreover, it is clearly understood now that merging trailer headers to headers as supposed by HTTP/1.1 is a security disaster. > > 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). Merging trailers with headers can happen somewhere else as long as you pass trailers through. And it will be perfectly in line with HTTP/1.1 specs. > > 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. The only potentially bad thing that can happen without forcing chunked transfer encoding is that trailers configured won't be sent if Content-Length is know. If this is critical for a use case, the Content-Length can be explicitly removed with additional configuration. Additionally, this is not something expected to happen when proxying, as Content-Length won't be known anyway if there are trailers in the upstream response. On the other hand, forcing chunked transfer encoding based on "TE: trailers" looks all the way wrong: - it will change the behaviour of nginx for such clients, even if there are no other reasons to do so; - it won't change the behaviour for other HTTP/1.1 clients who actually support trailers but doesn't advertize it via "TE: trailers", and thus trailers will be lost in some cases anyway. > > 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? I'm just asking for a description of at least one real-world use case for trailers, to better understand how they are expected to be used in real life. > > 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? Gzip is something you explicitly enable in the configuration to change the content of some responses. It changes the content, and this in turn results in chunked transfer encoding when using HTTP/1.1. In contrast, trailers is something exists only in case of chunked transfer encoding. Depending on the use case, it may make sense to either: 1. once trailers are configured, force chunked encoding and sent trailers (if it is possible to do so); or 2. once trailers are configured, sent them as long as chunked encoding is used. Obviously enough, second approach is more flexible. And, as long as there is a way to force chunked encoding by other means, allows to do exactly the same thing as the first one, plus some additional things. The first approach may be easier and more natural for some use cases. But as there are no real-world use cases described, there are no arguments to support this approach. -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel