outboundHostname does not seem to have any effect

[demaniak]

outboundHostname does not seem to have an effect

Essentially, I am trying to configure DFP to redirect to an absolute URL for a specific servicePath.

For example, http://a-domain.com/a routes to the backend as per normal, but http://a-domain.com/b results in a redirect to (for example) https://www.google.com

As an added complication, the serviceDomain value in question is set to two domains, comma separated. This is just for convenience, since the configuration becomes significantly larger if I treat the service domains separately also. Also, I'm ASSUMING (without actual proof) that this is supported with indexed labels.

A sample label configuration for a service could look like this (I am including items that may or not be relevant, just in case they ARE relevant:

      - com.df.servicePath.1=/
      - com.df.serviceDomain.1=a.co.za,b.co.za
      - com.df.port.1=8080
      - com.df.servicePath.2=/this-should-go-to-google
      - com.df.serviceDomain.2=a.co.za,b.co.za
      - com.df.port.2=8080
      - com.df.outboundHostname.2=https://www.google.com
      - com.df.notify=true
      - com.df.distribute=true
      - com.df.httpsOnly=true
      - com.df.addResHeader=Strict-Transport-Security max-age=31536000;\ includeSubDomains
      - com.df.xForwardedProto=true

Steps to reproduce the issue:

1. Configure a DFP enabled service in a stack with labels as demonstrated above
2. Deploy in a DFP enabled swarm

Describe the results you received:
DFP is successfully configured. The servicePath with value / successfully routes to the backend for both domains a.co.za and b.co.za.
The servicePath with value /this-should-go-to-google also routes to the backend service.

Examination of generated haProxy config shows no trace of https://www.google.com.

Describe the results you expected:
A request for servicePath /this-should-go-to-google should result in the client being redirect to https://www.google.com.
(Assuming my understanding of outboundHostname is correct!)

Additional information you deem important (e.g. issue happens only occasionally):

Additional environment details (AWS, VirtualBox, physical, etc.):

• running on ubuntu 16.04.03 LTS
• AWS
• proxy image: vfarcic/docker-flow-proxy:latest@sha256:e6f4ac8c4aab50b14ed097e0172fa0dc42b5cf6dae7b9c6b5862a53dbb01efb8
• listner image: vfarcic/docker-flow-swarm-listener:latest@sha256:73b59f38a8ce520d5528e81395412d143b159e6f2d1392760500f89facbd21ff
• removing the 2nd domain from the comma separated serviceDomain does not seem to have any effect.

[vfarcic]

The problem with the stack you're using is that DFP, at the moment, does not support indexing of outboundHostname.

Instead using:

- com.df.outboundHostname.2=https://www.google.com

It should be:

- com.df.outboundHostname=https://www.google.com

The initial idea is that all requests for a service would go to the same service. Judging from your scenario, you have a service but only part of requests should go to it and others should be forwarded somewhere else (whatever outboundHostname says). Is that the case or you used it only as a quick demonstration of the problem?

[demaniak]

Ahh ok, that would explain it.

Yes, we are rewriting an existing system (actually 99% done, we are approaching go-live), and certain aspects have been deemed out-of-scope for us.

But since the existing system...well... exists...we can't just 404 on those requests, we need to redirect them to a 3rd party that is now supplying those items.

[vfarcic]

Indexing outboundHostname is available starting from the release 17.10.12-41.

Please try it out and let me know if it works as you expected.

[demaniak]

@vfarcic thanks a million - I will do so as soon as possible, and report back :)