Content Type and the data serialization

[pstolarz]

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 in core/src/client/lwm2m_client_core.c and called during (among other possibilities) by LWM2M2 READ, we see:

static int SerialiseOIR(Lwm2mTreeNode * root, ContentType acceptContentType, int oir[], int oirLength, ContentType * responseContentType, char * buffer, size_t size)
{
    int len = -1;

    if (acceptContentType == ContentType_None)
    {
        /* If the content type is not specified in the payload of a response message,
        * the default content type (text/plain) is assumed; otherwise the content type
        * MUST be specified in using one of the supported Media Types.
        */
        acceptContentType = ContentType_ApplicationPlainText;
    }

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.

If the LWM2M Client doesn’t support that option or the LWM2M Server expresses no data format preference, the LWM2M Client will use its own preferred data format reported in the Content Format of the response message

so, such approach should be possible from the spec. point of view.

Regards & thanks for the great lib Piotrek

[cdewbery]

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.

[DavidAntliff]

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.

[delmet]

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.

[pstolarz]

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...

[pstolarz]

@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.