SpectoLabs / hoverfly

Lightweight service virtualization/ API simulation / API mocking tool for developers and testers

Home Page:https://hoverfly.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Hoverfly replaces "Host" header in SPY mode

ghazi94 opened this issue · comments

Description of the bug

I am using hoverfly-java (0.14.0) with my Spring project in integration testing.
My actual service (under test/spy) calls are routed through envoy which relies on the Host: X header - where X specifies the service name.
For example, this is the original request:

{
    "method" : "GET",
    "url" : "http://localhost:9211/sample-path/1",
    "queryStringParameters" : {},
    "headers" : {
      "Host" : [ "my-service.service" ],
      "Accept" : [ "application/json" ]
    }
  }

While using Hoverfly in SPY mode, it is proxying requests but replacing the Host header to finally have this request:

{
    "method" : "GET",
    "url" : "http://localhost:{hoverlfy-port}/sample-path/1",
    "queryStringParameters" : {},
    "headers" : {
      "Host" : [ "localhost:9211" ],
      "Accept" : [ "application/json" ]
    }
  }

This makes the underlying service unable to route requests.

Is it possible to specify custom header for Hoverfly to use internally for forwarding requests? Or can I explicitly re-set the header using a hack?

Steps to reproduce the issue

I can upload a sample project in the discussion below - however, the issue is easy to reproduce with SPY mode.

Observed result

404 Not Found due to wrong Host header

Expected result

200 OK

I went through some debugging and couldn't see anywhere in goproxy or hoverfly that would remove the Host header, and then I found this in the golang HTTP doc:

// For incoming requests, the Host header is promoted to the
// Request.Host field and removed from the Header map.

It's surprising to see that's how the go HTTP package behaves. As hoverfly doesn't see the original Host header, it cannot reconstruct the original request with the Host header value you supply.

You can read more about the original Go issue on Github: golang/go#7682

A workaround is probably to use a custom host header for routing, however I'm not sure if your envoy proxy supports it.