Thanks for the PR. Can you explain in more detail what problem this is solving ? What causes it, what the resulting errors are, what the resulting observable effect is ?

This seemed to confuse Jetty in the OpenHab instance.

I'm not sure what this means? Also what is generating requests without a content length or type header? Do these same requests happen against OH directly without the cloud service? How does OH deal with it then?

Sorry, I've been busy with my day job for a while and just getting back to this. This is a fix for:

OpenHAB-Cloud Issue 328

As I stated there, it might not be the RIGHT fix, but it does fix the problem (I'm new to Node.js, WebSockets, and the cloud code base). What seems to be happening to me is that when you trigger a rule manually (or have a button that triggers a rule):

1. The OpenHab console sends a POST packet with "content-size=0" and no "content-type" set.
2. If the connection is directly to OH, whatever process happens is fine with that and the rule runs.
3. If the connection is through the cloud service, the translation from a regular POST to an internal type packet happens and whatever process happens to to that inside OH does NOT like the new packet, and throws the error seen in Issue 328.

Currently, I have no ability to build the OH source and try things, only the cloud source, but my conjecture was that in OH it's seeing that "content-size" is set so it's looking to parse the data, but the "content-type" isn't set so it can't parse the data.

I guess in the end this might be an OH fix not a cloud fix, but this patch made it work for me.

I assume openhab/openhab-addons#10600 fixes this?