Fallback to application/octet-stream content type when for invalid UTF-8 message bodies so ServicePulse will not fail loading the BLOB#5394
Conversation
…data When a message body fails UTF-8 decoding despite the content type header claiming text, update the metadata content type to application/octet-stream and fall back to body storage instead of silently dropping the body.
ramonsmits
changed the title
application/octet-stream content type when for invalid UTF-8 message bodies so ServicePulse will not fail loading the BLOB
When a failed message body is not valid UTF-8 despite the content type header, update metadata and attachment content type to application/octet-stream. Replay is unaffected as it uses the original message headers, not metadata.
| contentType = "application/octet-stream"; | ||
| processingAttempt.MessageMetadata["ContentType"] = contentType; |
There was a problem hiding this comment.
It doesn't feel right to do this at the RavenDB implementation.
We are about to add more persistences and it feels like this should be handled by the framework not the specific implementions
There was a problem hiding this comment.
@johnsimons if you look at this from the perspective of the bug fix and also that the content type handling is already in place it seems totally OK as a transitionary solution
|
@danielmarbach @johnsimons I have give it some more thought. I added this to mitigate strange behavior of what I thought was wrong. However, later I found the cause for that was the transport message mutator breaking the headers: If the source states its json, but we cannot decode it.. that can have other reasons to. For example, it could be compressed and decompression is something that servicecontrol does not support while endpoints might. |
3 participants
Summary
DecoderFallbackExceptionhandler now updatesMessageMetadata["ContentType"]toapplication/octet-streamand falls back to body storageImpact on ServicePulse
contentTypeParser.ts: application/octet-stream falls into the application/ branch but doesn't match +json or +xml, so it returns { isSupported: false }.BodyView.vuewill show : "Message body cannot be displayed because content type application/octet-stream is not supported." This is an improvement over the current behavior where ServicePulse tries to parse binary data as JSON/XML and crashes.MessageStore.ts: the JSON/XML formatting try block won't trigger for application/octet-stream, so no parse errors.EditRetryDialog.vue: edit & retry will be disabled with a warning that the content type is not supported. Correct behavior for binary data.