Cloudeventsmiddleware has lost other properties of cloudevents

[saber-wang]

Describe the proposal

https://github.com/dapr/dotnet-sdk/blob/cc1b097991bbf268464b74935cdfbb35c0a26443/src/Dapr.AspNetCore/CloudEventsMiddleware.cs#L78

Should additional attributes be attached to the request header?

[halspang]

@saber-wang - Thanks for opening this issue! Are you just asking for additional properties to passed through to the subscription endpoint? Is this as opposed to providing them in the body of the message?

[saber-wang]

@halspang I just don't think we should throw away other attributes

[saber-wang]

@halspang Currently, direct publishing of cloud events is supported #868 . Should this issue be reconsidered?

[halspang]

@saber-wang - Circling back to this, if the raw cloud events doesn't work, I think it would be due to the runtime not actually passing the extra attributes through. If we want them here, we'd have to take care of it there first.

[imranmomin]

@halspang @saber-wang

I wanted to see if there is any workaround to access those cloud events attributes from request headers. I see that the current middleware does not capture all the attributes from the body and pass them into the header as specified in the their documents.

https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/bindings/http-protocol-binding.md#313-metadata-headers

[saber-wang]

@imranmomin At present, I have rewritten middleware and handled cloudevent properties myself

[imranmomin]

I guess I will also have to rewrite the middleware

[zryska]

It seems like this is becoming more popular. It might be beneficial to extend the cloudeventsmiddleware to avoid multiple implementations of the same functionality. Is this already captured in the backlog, and if so, could it be prioritized?