Restrictions to modifying request->headers_in.headers in NGX_HTTP_PREACCESS_PHASE?

[Ryan Burn]

The module is intended to support distributed tracing in a pluggable way.

The key/values of the headers added are generated from the module.
They're used to support cross process tracing
(http://opentracing.io/documentation/pages/api/cross-process-tracing.html)
so that the performance information recorded by this module can be
linked to the performance information reported by any other code that
processes the request.

Since the specific headers values used to propagate the tracing
context across processes vary by tracing system (for example zipkin
uses B3 headers https://github.com/openzipkin/b3-propagation), jaeger
uses headers like (uber-trace-id, uberctx-*, etc), I'd rather not have
any of those details be exposed to the nginx configuration.

Is there any way any way an arbitrary number of headers can be added
without requiring the configuration writer to know anything about
them?

On Thu, Mar 29, 2018 at 2:34 PM, Robert Paprocki
<rpaprocki at fearnothingproductions.net> wrote:
> Hello,
>
> On Thu, Mar 29, 2018 at 11:06 AM, Ryan Burn <rnickb731 at gmail.com> wrote:
>>
>>
>> This module injects multiple headers and the number, keys, etc aren't
>> meant to be exposed to the user.
>>
>> (This module is mean to support tracing and the injected headers btw
>> correspond to a SpanContext:
>> http://opentracing.io/documentation/pages/api/cross-process-tracing.html
>> which varies by the trace used).
>>
>> Is there way to accomplish this without having the configuration
>> author do anything?
>
>
>
> What's the source of these header names/values? If it's passed from the
> downstream client, it will automatically be proxied to the upstream server
> (with some exceptions, see the proxy module documentation).
>
> If it's generated on the Nginx node itself, you should be able to use the
> proxy_set_header Maxim defined above, in combination with variables which
> could be generated via your custom module or some other approach.
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel