Is more_set_input_headers safe?

[rnburn]

more_set_input_headers pushes to the request->headers_in.headers list.

While it behaves as expected most of the time, according to this post, you're not allowed to modify headers_in like that.

[dioni21]

Please, take a look at #105

[agentzh]

Yes, it's safe enough. We put a lot of effort here over the years and many people have been using it successfully in production.

@dioni21 That issue is more about the evilness of the map directive, not really a issue in this module.

[rnburn]

Yes, it's safe enough.

Developers on nginx-devel made clear: You're not allowed to modify request->headers_in.

While it may work most of the time, this same method of modifying headers_in caused kubernetes/ingress-nginx#2222 (comment)

Close the issue if you want, but what you're doing results in undefined behavior.

[agentzh]

@rnburn It is undefined by the official nginx team but we do work on the C level to make sure things work as expected with the rest of the nginx world. Note that we are also the developers of OpenResty. Nginx is just a component to us.

Your ingress-nginx ticket is not clear enough for the real issue since it has opentracing frames injected into the stack. If you believe there is a bug, please file a ticket here with minimal and standalone example that can reproduce the issue easily.

[agentzh]

There are so many so-called "undefined behaviors" by the nginx team. If we stick with Nginx's own very limited agenda and recommendations, most of our 3rd-party modules wouldn't exit in the first place. We only care about implementation details, not what they are saying. The latter is never really helpful in my years of experience in the nginx world (more than a decade now).

[agentzh]

"Only in code we trust" :)

[agentzh]

@rnburn Just see how #105 turned out to be an old bug in the nginx core which is completely unrelated to this module. People may blame this module for others' fault. It happens (and I do understand).