fnproject / fdk-java

Java API and runtime for fn.
Apache License 2.0
142 stars 53 forks source link

try to add user agent? #200

Closed rdallman closed 3 years ago

rdallman commented 5 years ago

I highly doubt this will work. we appear to have some strange incantation of looking at release.version to release this thing, from some cursory googling something like this can get the version of the fdk we're using at runtime, but I am not exactly sure how to do it. I suspect someone fluent in java things can do this in a few seconds, if I could ask for a little hand here, I think this is the right place to put it.

tzezula commented 5 years ago

By default Maven does not include implementation version in manifest. The addDefaultImplementationEntries has to be used, see https://maven.apache.org/shared/maven-archiver/examples/manifest.html.

It does not work in substrate, tested with rc16. I will create an issue.

rdallman commented 5 years ago

Why are we setting User Agent on the server side ? That’s not right - surely should be Server or a custom header

yea, Server header makes more sense, thanks.

zootalures commented 5 years ago

Would rather we used a custom-header here (Fn-Fdk-Version?) and let that bubble out of the invoke API - saves Server for whatever is serving the request at the front - we already notionally reserve Fn-* for ourselves so I think that fits.

rdallman commented 5 years ago

yea, I feared messing with the build. this task is a bit more painful than it appears on the surface to be able to get the version at runtime (across all supported langs). hoping to enlist some support.

Fn-Fdk-Version

👍 i'm good with this. i hadn't quite gotten to figuring out whether to let it leak out to users or just strip it and use for metrics, from a client perspective (who may have no clue there's an fn function underneath the request) it seems like an odd thing to see, but so is Server in that sense I guess.

zootalures commented 5 years ago

On the Invoke API it's explicitly a functions API and it won't leak to triggers so don't see any big issues with echoing it back - agree it leaks a bit but it's no different to returning an accurate Server header for instance.