ContentType decode exception
See original GitHub issueHello,
I receive this expcetion while I try to deserialize event which I receive from Azure Service Bus. Excaption:
The 'contenttype' attribute value must be a content-type expression compliant with RFC2046
at CloudNative.CloudEvents.CloudEventAttributes.ValidateAndNormalize(String key, Object& value)
at CloudNative.CloudEvents.CloudEventAttributes.set_Item(String key, Object value)
at CloudNative.CloudEvents.JsonEventFormatter.DecodeJObject(JObject jObject, IEnumerable`1 extensions)
at CloudNative.CloudEvents.JsonEventFormatter.DecodeStructuredEvent(Byte[] data, IEnumerable`1 extensions)
The event looks like this:
{
"DataContentType": {
"Boundary": null,
"CharSet": null,
"MediaType": "application/json",
"Name": null,
"Parameters": []
},
"Data": {
"OrderNumber": "#",
"TrackingNumber": "#",
"StateId": 5
},
"Id": "dbb05af1-d0fb-46ee-9c8e-df585c02362a",
"DataSchema": null,
"Source": "http://localhost:61974/",
"SpecVersion": 3,
"Subject": "510589659",
"Time": "2020-11-20T05:26:56.8365438Z",
"Type": "trackandtrace.order.statechanged"
}
Event creation looks like this:
var message = new CloudEvent(Types.OrderStateChanged, _configuration.BaseUri)
{
Data = new TransportStateChanged
{
OrderNumber = orderInfo.OrderNumber,
TrackingNumber = orderInfo.TrackingNumber,
StateId = orderInfo.StateId
},
DataContentType = new ContentType("application/json"),
Subject = orderInfo.OrderNumber
};
Event deserialization is done by JsonEventFormatter
with byte[]
parameter.
Is there anything that I miss when I create or deserialize message?
I check JsonEventFormatter
code and maybe this is the problem
switch (item.Value.Type)
{
case JTokenType.String:
attributes[item.Key] = item.Value.ToObject<string>();
break;
case JTokenType.Date:
attributes[item.Key] = item.Value.ToObject<DateTime>();
break;
case JTokenType.Uri:
attributes[item.Key] = item.Value.ToObject<Uri>();
break;
case JTokenType.Null:
attributes[item.Key] = null;
break;
case JTokenType.Integer:
attributes[item.Key] = item.Value.ToObject<int>();
break;
default:
attributes[item.Key] = item.Value;
break;
}
bacause in CloudEventAttributes
is value type compared to string
or ContentType
but actual type is Newtonsoft.Json.Linq.JObject
Issue Analytics
- State:
- Created 3 years ago
- Comments:17 (9 by maintainers)
Top Results From Across the Web
Unable to decode content with header X-Content-Type- ...
when i run this below code, im getting the output printed in different characters. but works perfect and gives a html string on...
Read more >Decode with utf8 by default for non-text (or all?) content types
I am requesting some information from the a server, which returns the following (using postman): Headers: Allow →GET, HEAD, OPTIONS CF-RAY ...
Read more >Class UnsupportedMediaTypeStatusException
Constructor for when trying to encode from or decode to a specific Java type. UnsupportedMediaTypeStatusException(MediaType contentType, List<MediaType> ...
Read more >application/json; charset=test" cause an error · Issue #3562 ...
Long story short Request's header Content-Type encoding have not validated properly. bytes_body.decode(encoding) raise as error ...
Read more >Character set error when trying to import from web API
Fail to read from REST resource. The character set provided in ContentType is invalid. Cannot read content as string using an invalid character ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Seems this is a change in .NET5. This have broken a few APIs here after upgrading.
Also reproduced here: dotnet/aspnetcore#29343
There’s still quite a lot of work to do before we can release 2.0. (Just look at all the TODOs around, as well as the issues.)
Basically I see 2.0 as our final chance to get the public API “right” - there are few enough users of 1.0 that we’re happy to take breaking changes to get to 2.0, but I’d expect 2.0 to get a lot more traction (due to CloudEvents themselves getting more traction) - so we need to be careful.
I’d like to hope that it’ll be mid-Q2, but I’m not promising anything.