Support For Dynamic Headers

[darylrobbins]

Add support for dynamic HTTP header values by using a handlebars template as the heaver value instead of a static value. This allows header values to be derived from other headers or other attributes of the request.

For example:
x-original-proto: {{headers.x-forwarded-proto}}

[GUI]

Thanks! This looks great, and this seems like like a handy feature. Just a couple of quick comments.

• Can you add a test? That would just help ensure we don't accidentally break this functionality in the future.
  • Here are the existing tests for setting headers. I think a test for this would look very similar to the "overrides existing headers (case insensitive)" test, except you'd make the request with an X-Forwarded-Proto value, and then make sure the X-Original-Proto value matches on the response. You'd also need to add this handlebars-ified example to the header settings.
• There may be some very slight performance implications of this change, since all header overrides are now being treated as a handlebars templates (so even if handlebars aren't being used in the header value, it's still being parsed as one). However, you did exactly the right thing with pre-compiling the handlebars template inside the configReload method, so I think this is about as optimized as it's going to get with a handlebars approach (which might be overkill for renaming a header, but it is flexible and also jives with how we've handled templateizing some of the other settings). Anyway, I digress--I'm good with this, and it seems like a solid approach.

Thanks again! And if you don't have time to add a test, or you're not comfortable in the testing code, I'd be happy to add one, but it might be tomorrow before I can do that.

[darylrobbins]

I will see if I can get a test going tomorrow morning.

I figured it wasn't worth handling templates and non-templates separately. I have to believe Handlebars generates a compiled template for static text that doesn't result in much overhead. I wouldn't be surprised if they have optimizations for this special case.

I guess we'll have to think about how we implement this feature in Lua land as well.

[darylrobbins]

I have added a reasonably complete test suite for dynamic headers, exercising some of their more advanced capabilities. I have the per API and sub-url cases covered. Are there any others that may not be covered by the api_matcher? (i.e. global headers across all APIs?)

I made a design decision that if the handlebars template evaluates to nothing, the header will not be set. So, this would allow you to set/override a header only if another header had a value for example. For example, use x-forwarded-proto as-is unless x-original-proto has a value, in which case use it. You also have access to use default values through handlebars (example includes in the tests). Given this decision, you would not be able to remove a header though using the dynamic headers. Thoughts?

[GUI]

Fantastic, thanks so much for the pull request and additional tests!

This will be part of the v0.7 package releases, that I meant to get to last week, but will try to definitely get to this week.

[sandeeepk]

I have to add Headers in Global RequestSetting but there is no to add in Analytics Path These are all doing in Api Umberlla