Closed pstolarz closed 8 years ago
Hi Piotrek,
Thank you for the detailed report.
During our compatibility testing we found that this particular case was not handled very consistently across various implementations. We ended up settling on plain text, as I think this may have been listed as the default at one stage in one of the many revisions of the specification(although don't quote me on that). I think your idea to be able to set the default content type is a great idea and would allow for better compatibility with the likes of Leshan.
Chris.
We have an option on the server to set the default content encoding type - would it be useful to add a similar option to the client?
Note that during the January 2016 TestFest, it was decided that the content type must be specified in all requests, and that the standard will be updated to say so, so once the spec is finally published as 1.0 "final" and Leshan is updated, the problem should diminish.
I have tried testing change against leshan.eclipse.org to confirm fix but not seeing issue. As it always seems to provide either accept or content format header.
You wont see any difference between the versions w/ and w/o your fix, since the fix is incomplete - see my comment for #258. After applying my patch, launch awa_clientd w/o -t option. Then look into your registered client via the web interface in the leshan demo server and try to read a whole instance of any object. You will get an alert in leshan like this one:
Unable to read instance /1/0 for pstolarz : 500 Client [pstolarz] returned unexpected response code [2.00]
and
[ERROR] Serialiser not found for type 0
on the awa_client side.
Next launch the client with -t 1542 (or any other type supporting full serialization) and everything will work fine.
BTW: Why not to use application/vnd.oma.lwm2m+tlv encoding (1542) as the defualt one? Less problems in the future.
And thanks for the blitz response and fix. Impressive...
@delme-imgtec Indeed, checking today's version of leshan.eclipse.org it looks like they provided a new version which always sends a content type for requests. See their yesterday change:
https://github.com/eclipse/leshan/commit/86295f9821db1766135d406019b859d8fee5a7c7
Looks like they use 1542 type from now. The change was introduced 23 hours ago, so yesterday I worked with an old version and today they upgraded the server.
On my development version (leshan-0.1.11-M12 - still the latest tag) the problem exists.
During an integration my libawa client with the leshan demo server I found an issue related to the Content Type used by the data serialization process. For
SerializeOIR()
located incore/src/client/lwm2m_client_core.c
and called during (among other possibilities) by LWM2M2 READ, we see:which seems to be a copy-paste version of the same code in
DeserializeOIR()
. But, whereas it is feasible to assume the content type will be always present in the response msg, (see sect. 6.3 in the "Lightweight Machine to Machine Technical Specification") it is a common case the content type spec. will be absent in requests. This leads to assuming the default content type as text/plain and an error while serialization data other that single resources.I would rather recommend to use application/vnd.oma.lwm2m+tlv for this case OR use a configuration arg. specifying the default content type. According to the mentioned spec.
so, such approach should be possible from the spec. point of view.
Regards & thanks for the great lib Piotrek