Prebid Server Version Info

[SyntaxNode]

We have received several requests to add the ability to retrieve the version number of Prebid Server. There is an existing version endpoint today which contains the truncated commit hash, but this is only available on the admin port which users cannot access. It also does not provide information as to exactly which version of Prebid Server handeled the request.

Question:

1. Should we update the existing endpoint to add the version and full commit hash and also make it available in the public API? ... or leave the existing endpoint alone to maximize compatibility and add a new endpoint publicly?

We discussed extending the existing /status endpoint, but the response is not json and thus would require a breaking change to extend. I propose we add a new '/version' endpoint which will respond with the following json including both the friendly version number and the git hash:

{
  "version": "0.98.0",
  "hash": "bd43afbca80114e76d1b14a2843b71f8a5f62894"
}

The default values would be "0.0.0" for the version and an empty string for the hash for local builds.

Questions:

1. Should we include the name/path of the repository as well to account for potential forked builds?

It may also be worthwhile to include the version information in the http response headers, so in the case of a mixed deploy scenario you would know exactly which version handled the request, such as:

Server: prebid/0.98.0

Questions:

1. Is this worthwhile to do?
2. Should we use a different header key to avoid possible conflict/overwriting by networking middleware and proxies like nginx?

[benjaminch]

Hey @SyntaxNode

I think there is already a /version endpoint for PBS.
Endpoint implementation and tests

Original issue and PR.

This can be extended if needed though :)

Cheers

[SyntaxNode]

Thank you for posting the original issue.

The existing endpoint is exclusive to the admin port which the users of the service cannot access. I don't personally see the need to keep this information restricted. The original argument against making it publicly available is two fold:

Since anyone can easily compile any version with any -ldflags, it's quite fragile. I'd rather that publishers didn't learn about this endpoint and believe they could trust it.

That is certainly true, but that logic applies to any open source project. I don't view this as a deal breaker.

This keeps our API's surface area smaller, which is good for project maintenance. Since your use-case is a dev one, we don't need to expose it to publishers.

I'm not worried about the level of effort needed to support a public version endpoint.

I'll update the proposal to consider the existing admin only endpoint. For the sake of compatibility, we may wish to leave it alone. I don't want to break anyone and I have no idea if any other hosts are making use of that endpoint for reporting.

[benjaminch]

I agree with you, this one should be accessible not only from admin port. Maybe we can consider moving it to non admin and redirect admin to the non admin /version not to break existing usages?

[SyntaxNode]

Cool. Let's expand the current endpoint to include the tag version. I think it's best to keep the admin version to maximize compatibility.

How do you feel about...?

1. Including the full commit hash instead of just the short one? To maximize compatibility, the short one needs to remain.
2. Including the tag version in the header of server responses.

[benjaminch]

Hey @SyntaxNode !

I think both 1 and 2 sound great ;)

[bretg]

@SyntaxNode - what's the version for PBS-Go? Tried https://prebid.adnxs.com/pbs/v1/version

This is what PBS-Java returns -- https://prebid-server.rubiconproject.com/version

{
revision: "18fbd5d788a0a2bb4a76c1b86602a4865a4b0338",
version: "1.51.1"
}

[ncolletti]

@SyntaxNode Bumping Bret's question, will the PBS Go version support the /version endpoint?

[SyntaxNode]

@ncolletti Yes. We absolutely plan to support the public version endpoint. It's on our list for this year, but it's not on the top of the list so I can't offer an ETA. We welcome community contributions and can provide guidance for folks who would like to implement this sooner.

[SyntaxNode]

Implemented in PBS-Go 0.179.0. I opened a separate ticket #2010 to track the response header.