Producing with different embedded formats across multiple HTTP requests isn't honoured

[ppatierno]

When an HTTP producer connects to the bridge, a new "source" endpoint is created with the requested embedded format (json, or binary) and then the corresponding message converter is created for that endpoint.
The endpoint is related to the HTTP connection (the bridge holds a map HTTP connection - source endpoint) so it's always the same until the HTTP producer disconnects.
But, during its activity, an HTTP producer could send requests with different Content-Type, i.e.

On 1st (when connecting) it sends JSON --> the "source" endpoint is created with JSON format and JSON message converter
Second time, JSON --> still using same "source" endpoint, ok!
Third time, binary --> still using same "source" endpoint, ko! Using a JSON message converter for a "binary" data!
...
...

When it comes to send a different data format, the bridge is still using the format and corresponding message converter created on first send which is bad. It should be able to use a different message converter, i.e. the binary one in the above example.
Can we consider this as a bug, or we could expect that a producer, when connected, will send same data format until disconnecting? So we could assume the first producing call will set the format (specified in the Content-Type) for the entire life of the producer until it disconnects? Returning error if it doesn't match?

NOTE:
This behaviour (set data format at the beginning) is what we have for consumers, but they have a different life on the bridge so it makes more sense.
You create a consumer (through the creation endpoint) and specify the format. A dedicated consumer endpoint is created and it's used for poll requests (even on different connections). The bridge verify the Accept header is consistent with the embedded format on creation.

[scholzj]

There is no producer creation command, nor is there any producer ID or anything, or? You just use POST to send messages as individual HTTP requests IIRC. So how do you disconnect? On the TCP level? If we had some producer ID or some separate mechanism for a producer session as we have for consumers I would think it would be reasonable to say that the session uses always the same format and if you want to send different messages you should create another one. But with it happening only inside the HTTP client, it would seem quite strange to me.

So I would say this is a bug.

[ppatierno]

On the producer side, the "life session" is related to the "HTTP connection" lifetime. But yeah, if your producer has keep-alive and the HTTP connection is never closed, it could send requests with different Content-Type (json, binary, ...) but in the current implementation it wouldn't work (always using JSON).
I am going to create an issue from this discussion.
The behaviour will be that, because every HTTP request from a producer brings the Content-Type, the bridge has to handle the specific format each time (even if the HTTP connection is still the same).