<p>I have a Django application running in a container that I would like to probe for readiness. The kubernetes version is 1.10.12. The settings.py specifies to only allow traffic from a specific domain:</p>

<pre class="lang-py prettyprint-override"><code>ALLOWED_HOSTS = ['.example.net']
</code></pre>

<p>If I set up my probe without setting any headers, like so: </p>

<pre><code>      containers:
      - name: django
       readinessProbe:
          httpGet:
            path: /readiness-path
            port: 8003
</code></pre>

<p>then I receive a 400 response, as expected- the probe is blocked from accessing <code>readiness-path</code>:</p>

<pre><code>Invalid HTTP_HOST header: '10.5.0.67:8003'. You may need to add '10.5.0.67' to ALLOWED_HOSTS.
</code></pre>

<p>I have tested that I can can successfully curl the readiness path as long as I manually set the host headers on the request, so I tried setting the Host headers on the httpGet, as <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes" rel="nofollow noreferrer">partially documented here</a>, like so: </p>

<pre><code>        readinessProbe:
          httpGet:
            path: /readiness-path
            port: 8003
            httpHeaders:
              - name: Host
                value: local.example.net:8003
</code></pre>

<p>The probe continues to fail with a 400.</p>

<p>Messing around, I tried setting the httpHeader with a lowercase h, like so: </p>

<pre><code>        readinessProbe:
          httpGet:
            path: /django-admin
            port: 8003
            httpHeaders:
              - name: host
                value: local.example.net:8003
</code></pre>

<p>Now, the probe actually hits the server, but it's apparent from the logs that instead of overwriting the HTTP_HOST header with the correct value, it has been appended, and fails because the combined HTTP_HOST header is invalid:</p>

<pre><code>Invalid HTTP_HOST header: '10.5.0.67:8003,local.example.net:8003'. The domain name provided is not valid according to RFC 1034/1035
</code></pre>

<p>Why would it recognize the header here and add it, instead of replacing it? </p>

<p>One suspicion I am trying to validate is that perhaps correct handling of host headers was only added to the Kubernetes httpHeaders spec after 1.10. I have been unable to find a clear answer on when host headers were added to Kubernetes- there are no specific headers described in the <a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#httpheader-v1-core" rel="nofollow noreferrer">API documentation for 1.10</a>. </p>

<p>Is it possible to set host headers on a readiness probe in Kubernetes 1.10, and if so how is it done? If not, any other pointers for getting this readiness probe to correctly hit the readiness path of my application?</p>

<p><strong>Update</strong>:</p>

<p>I have now tried setting the value without a port, as suggested by a commenter:</p>

<pre><code>            httpHeaders:
              - name: Host
                value: local.acmi.net.au
</code></pre>

<p>The result is identical to setting the value with a port. With a capital H the host header value is not picked up at all, with a lowercase h the host header value is appended to the existing host header value.</p>

<p>Steven Shaw's answer was very useful, but the winning combination wound up finally being:</p>

<pre><code>readinessProbe:
          httpGet:
            path: /readiness-path/ # &lt;&lt; NO REDIRECTS ON THIS PATH
            port: 8003
            httpHeaders:
              - name: host
                value: local.example.net # &lt;&lt; NO PORT ON THE HOST VALUE
</code></pre>

<p>After some log contemplation I finally realized that the path I was probing for readiness was redirecting from <code>/readiness-path</code> to <code>/readiness-path/</code>. Once I supplied the trailing slash to sidestep the redirect, it started working. From this I conclude that the redirects weren't preserving the httpHeaders being set on the probe request.</p>
