SecureProxy should identify itself

[cnelson]

In order to quickly understand where nginx-generated error messages are coming from, as an operator or customer of the cloud.gov platform I want errors from secureproxy to be clearly identified.

[LinuxBozo]

Would it make sense instead of modifying the source, to just add the headers_more plugin and do this in configuration?

server_tokens off
more_set_headers 'Server: something'

[cnelson]

IIRC headers_more requires lua which I don't think we are compiling in right now

[LinuxBozo]

Looks like we used to have headers_more and yanked it when we weren't actually using it: https://github.com/18F/cg-secureproxy-boshrelease/pull/11/files

[cnelson]

Have exceeded white-noise on this one; Turned this PR into a card and put it at the bottom of atlas triage: https://favro.com/card/1e11108a2da81e3bd7153a7a/18F-4870

[brittag]

When this gets picked up from triage, might be interesting to chat with customer squad or me for like 5 min about options for what the Server message could say - for example, cloud.gov secureproxy is more meaningful than nginx but still might puzzle readers (in the rare case that they see it) since they don't usually know what secureproxy means in the way that we use it. Not sure what a plainer-language version might be though.

[rogeruiz]

If I'm reading this properly, this will cause the server to respond with a header. so the error may still look the same, but we'd be seeing something like this below for better debugging:

$ curl -I https://my.app.cloud.gov/
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 13815
Connection: keep-alive
Accept-Ranges: bytes
Cache-Control: max-age=300
Date: Wed, 03 May 2017 04:19:54 GMT
ETag: "5908e0f6-35f7"
Last-Modified: Tue, 02 May 2017 19:41:42 GMT
Server: cloud.gov secureproxy
#       ^^^ would say this instead of `ngnix`

[jmcarp]

We were talking about using headers_more instead--did we not want to go down that route?