Update Items via RESTapi requires new header-data in OH3

Hi all

I moved from OH2 to OH3. I’m using file-configurations from OH2.
I have 3 IoT devices in my smart home. They are design to use the OpenHAB restAPI for items update (push-information to OH).

OH2 Setup was working perfectly with these HTTP message:

POST /rest/items/TFTStatusJSON HTTP/1.1
Host: 192.168.xx.yy
Connection: close")
Content-Length: 14
**empty line**
[some values for the item]

I do get now in OH3 error message like:

2021-09-03 13:30:14.557 [ERROR] [rg.apache.cxf.jaxrs.utils.JAXRSUtils] - No message body reader has been found for class java.lang.String, ContentType: application/octet-stream
2021-09-03 13:30:14.562 [WARN ] [s.impl.WebApplicationExceptionMapper] - javax.ws.rs.WebApplicationException: HTTP 415 Unsupported Media Type

Looking to the binding, I saw the following “new” required content-type:

curl -X POST --header "Content-Type: text/plain" --header "Accept: application/json" -d "OFF" "http://{openHAB_IP}:8080/rest/items/My_Item"

How can I use OH3 restAPI without the “Content-Type: text/plain” in the request stream?
I cannot access the installed IoT to change the API-request in short.
Any ideas


According to OH2 REST API documentation which you can find at openHAB REST API | openHAB there isn’t any difference between the REST API call that you describe you have to use for OH3 and the REST API call that is documented for OH2.

So my interpretation of this behavior is that your implementation of the REST API call for OH2 worked by accident. It may be that defaults for missing Content-Type now is application/octet-stream while it before was text/plain

Looking into the RFC that specifies HTTP request methods what you get is exactly that what is described in the RFC: rfc2616

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type “application/octet-stream”.

SHOULD in the above quote is defined as

This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Safest is to add the missing header.

It might be possible to use a CGI script running on a minimal web server that acts as a proxy, receives the request from your IOT; adds the missing header and sends the request to OH3; the proxy then needs to return the result to your IOT. Also this would require a change in your IOT which is even more effort than adding the header.

Thank you Wolfgang for your reply.

It was the resAPI design of OH2 which was leading to the exclusion of adding the header information for the stream. It was even more that the HTTP transfer was interrupted or even stopped by OH2 server when using header information at all. I cannot recall, if a timeout in the stream for the IoT or from OH2 server stopped the connection. I added security buffer in the IoT in order to transfer the 9 bytes usage data before going into closing connection to OH2 server.

You are saying, it is same implementation than OH2. But way do I get then theses errors only in OH3? What has been changed? I used the setup in OH2 for many years.

Cheers, Markus

The first link I posted shows that the curl examples for POST commands use that header.
The RFC explains that the header SHOULD be used and the server side may do interpretation on to do something if the header is missing.
That interpretation seems have to defaulted to text/plain while it is now the octect-steam as also according to the RFC/“internet specification”. So how OH3 now behaves is even more according to the spec.

I wrote that the examples already showed that the additional header needs to be used.
And you get the errro in OH3 because the default fallblack was changed.
It just worked by accident before. This header has to be defined.

Don"t forget dissimilar Java environments are involved. Maybe jetty is more picky.

It seems the Jetty restAPI server can not worked arround, neither is there any option of configuration. Then, I can only change my littles IoT. I will implement some setups and come back to this thread during weekend. Thanks so far.