Encode SSE based on HttpContentCodec (#2695) #2951
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current impl. of SSE uses special casing in the
EncoderDecoder
. Since we now have a generic way of handling en/decoding withHttpContentCodec
, we don't need this anymore and can use a custom SSE content codec. This has also the benefit, that creating a codec for SSE and trying to change the content type, will lead to an error, since onlytext/event-stream
has a codec defined.I see this also as a fix to #2695. The issues arose because we selected
application/json
has the media type and it was flagged asbinary
in an old zio-http version. Which is no longer the case. But this fix prevents it from ever using any other content type thentext/event-stream
, except it is forced by the user.Also, the encoding of SSE is currently bugged on main, since it is encoded as json based on the schema. This PR fixes that as well.
fixes #2695
/claim #2695