Producing with different embedded formats across multiple HTTP requests isn't honoured
ppatierno opened this issue · comments
Discussed in #873
Originally posted by ppatierno February 29, 2024
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.
As discussed, we could consider this a bug.
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).
As discussed, we could consider this a bug. 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).
I can't see any work around yet, my first assumption is that we are using the same producer over and over with to produce a message with the same content-type (as defined in the first request).
As discussed, we could consider this a bug. 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).
I can't see any work around yet, my first assumption is that we are using the same producer over and over with to produce a message with the same content-type (as defined in the first request).
I wonder how it happens because HTTP is stateless, so each request should be independent of another, mainly the ones prior to it.