Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HCM route request_headers_to_add cannot evaluate upstream host info correctly #12236

Closed
lambdai opened this issue Jul 22, 2020 · 4 comments
Closed
Labels
area/http stale stalebot believes this issue/PR has not been touched recently

Comments

@lambdai
Copy link
Contributor

lambdai commented Jul 22, 2020

UPSTREAM_METADATA is referring to the metadata in HostDescription, which is reasonable IFF
an upstream host is selected.
However, the evaluation is invoked before the upstream is selected so we can never encode the upstream
info into the header to upstream.

Approach:
Instead run header evaluation during route decoding the downstream header, push back to onPoolReady()
beside the parent_.downstreamHeaders()->setHost(host->hostname());

I evaluate twice which is not ideal but it solve my problem.

+++ b/source/common/router/upstream_request.cc
@@ -378,6 +378,9 @@ void UpstreamRequest::onPoolReady(
     parent_.downstreamHeaders()->setHost(host->hostname());
   }
 
+  parent_.routeEntry()->finalizeRequestHeaders(*headers, parent_.callbacks()->streamInfo(), <Expose insert_envoy_original_path flag to RouteInterface>);

Example config:

    - filters:                                                                                                                                                  
      - name: envoy.http_connection_manager                                               
        config:                                                                           
          codec_type: auto                                                                
          stat_prefix: tls_back                                                           
          route_config:                                                                   
            name: local_route                                                             
            virtual_hosts:                                                                
            - name: backend                                                               
              domains:                                                                    
              - "*"                                                                       
              request_headers_to_add:                                                                                                                                                 
              - header:                                                                                                                         
                  key: X-istio-original-port                                                                                                                                        
                  value: "%UPSTREAM_METADATA([\"istio\", \"port\"])%"                                                                                           
                append: true    
  - name: echo_cluster
    connect_timeout: 1s
    type: strict_dns
    lb_policy: round_robin
    load_assignment:
      cluster_name: "echo_cluster"
      endpoints:
        lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 15008
          metadata:
            filter_metadata:
              istio:
                port: "80"

@lambdai
Copy link
Contributor Author

lambdai commented Jul 22, 2020

I moved finalizeRequestHeaders to this place. all test cases except 2 cases expect the function be invoked there failed, which is not hard to update test cases.

Please let me know if you have any concerns on move the finalizeRequestHeaders which is not captured by the tests

@zuercher
Copy link
Member

I think I'd want to see the PR to understand better the effect of the change.

@stale
Copy link

stale bot commented Aug 29, 2020

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

@stale stale bot added the stale stalebot believes this issue/PR has not been touched recently label Aug 29, 2020
@stale
Copy link

stale bot commented Sep 6, 2020

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/http stale stalebot believes this issue/PR has not been touched recently
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants