I have a Internet facing service that provides APIs over https – json, xml and the like – something like https://api.example.org/api/foo. The API's are generally built from corporate internal services, but even if we are making requests to external internet based service I want them to appear to clients as my services.
From a User-Agent perspective https://api.example.org is the Origin server.
We have bought a fancy vendor API gateway product to secure the APIs. So far so good.
Currently the gateway is appending a Via header to the requests which contain the internal hostname of the server that processes the request, which is not so good.
> GET /api/foo/bar HTTP/1.1
> User-Agent: curl/7.37.1
> Host: api.example.org
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Thu, 15 Mar 2015 22:11:46 GMT
< Max-Forwards: 20
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< Via: 1.0 myinternalhostname.local (Apache-Coyote/1.1)
< transfer-encoding: chunked
< Connection: keep-alive
Whether they can use it or not, I dont want the bots and bad guys knowing my hostnames.
Can I remove the Via header, or should I sanitise it to the public name, eg
< Via: 1.0 api.example.org (Apache-Coyote/1.1)
I know why the Via header exists and I don't think my api server needs meet the RFC since its acting as an Origin server. (even though in reality it's a gateway/reverse proxy, the client doesn't need to know this).
TL;DR
Is it safe to remove the Via header from an Origin server?
Best Answer
The Via header is designed for passing the blame on to someone else.
It is perfectly acceptable to remove, or not generate it, if it doesn't serve that purpose.