feat: add /env endpoint to allow exposing operator-controlled info from the server

[liangyuanpeng]

It can return some env to user, like

set HTTPBIN_VERSION=v1 for go-httpbin adn request /env, it can be return :

{
  "envs":{
   "version":"v1"
  }
}

[mccutchen]

Is the idea that this new /env endpoint would return all environment vars prefixed with HTTPBIN_?

I'm not sure I see a ton of value here, but I'm curious what use cases you have in mind. Is this mainly a way to let the operator of a go-httpbin instance provide arbitrary data to clients?

[mccutchen]

Gonna close this for now. Feel free to re-open with more context!

[charlesvhe]

Hi @mccutchen , I'm looking for this feature too.

My scenario is used to quickly verify gray release (traffic control), which requires differentiating between instances. For example, deploy go-httpbin instance A with ENV label=instanceA, instance B with ENV label=instanceB, and then implement traffic control through API gateway or Istio configuration. And verify the /env return to check the instances is right or not.

The current solution is to mount different images and access /image/jpeg to confirm which instance it is returning.

I think just return all environment vars is OK.

[mccutchen]

Thanks for the additional context @charlesvhe, I'll re-open this. Are you interested in taking a pass at implementation?

I think just return all environment vars is OK.

I would not do this by default, to minimize the risk of unintentionally leaking sensitive information. Instead, we should only respond with env vars matching a particular prefix (e.g. HTTPBIN_* or HTTPBIN_ENV_*), so that operators may explicitly expose some env vars as necessary.