sdk-go
sdk-go copied to clipboard
How to properly set Content-Encoding?
We are using cloudevents/sdk-go (v1.2.0) to forward payloads to our request logger.
Triton server recently (sometime between 20.08 and 21.08) started to respect Accept-Encoding header and now returns gzip encoded payloads. This is indicated by the Content-Encoding with gzp value in response headers.
For our request logger to properly understand that payload we need to add this header to the CloudEvent.
It seems that there was a method to do exactly that https://github.com/cloudevents/sdk-go/blob/1f43b93ee854c847ce26d08f8433a0b0e3016c4f/pkg/cloudevents/event_writer.go#L100-L107 but now it is deprecated
deprecated: SetDataContentEncoding is not supported in v1.0 of CloudEvents
What would be the best way to add this header?
I think the http net libs will just do this automatically for us here. If the client gets a gzipped payload, it should unzip it and then the normal processing should continue working.
I don't recall the exact version, but we tried to remove the separation between the data and the content type. So we introduced a new method for setting data and content type at the same moment: https://github.com/cloudevents/sdk-go/blob/main/v2/event/event_data.go#L21
Is that what you are looking for?
OH. oh my I just noticed you are using v1 of the SDK. Please update to v2, we have a ton of performance improvements between v1 and v2 as of today. v2 is likely 4-8x faster than what you are using.
Please let me know if you have a blocker for migrating to v2. I have not been maintaining the v1 branch for about 2 years.
But how to do this in with pubsub?
Looks like this is implemented https://github.com/cloudevents/sdk-go/blob/main/protocol/pubsub/v2/write_pubsub_message.go#L70
think we can close this?
Looks like this is implemented https://github.com/cloudevents/sdk-go/blob/main/protocol/pubsub/v2/write_pubsub_message.go#L70
So, goal is to set Attribute Content-Encoding to zstd on a PubSub Message.
Can you please provide an example how you think this can currently be done?
FWIU, Transformers are not exposed via Client.Send. So first step seems to be to build an own (proxy) Protocol to be able to access Transformers. Then it seems like Version only allows for Attribute keys, that are defined by the spec. Thus it probably also is necessary to implement an Attribute implementation, which allows for arbitrary keys allowed by PubSub.
And even then pubsubMessagePublisher currently enforces a ce--prefix on Attributes.