OrthancPluginHttpClient httpStatus bug?

Hi guys,

I’d like to ask for help in identifying and reporting what I believe is a bug in 1.3.2.

As it seems, OrthancPluginHttpClient does not update its fourth parameter (httpStatus) when the remote server returns an error code. Here’s a log snippet from a recent execution:

W0718 20:14:03.581804 PluginsManager.cpp:168] Notifying overseer that instance 1.2.826.0.1.3680043.8.1055.1.20161012115906794.727793486.2431137 has arrived
I0718 20:14:03.585097 HttpClient.cpp:647] Error in HTTP request, received HTTP status 415 (Unsupported Media Type)
E0718 20:14:03.585259 PluginsManager.cpp:197] Exception while invoking plugin service 27: Error in the network protocol
E0718 20:14:03.585295 PluginsManager.cpp:164] Unexpected error during call to Overseer: 500
E0718 20:14:03.585335 ServerContext.cpp:226] Error in the plugin callback while receiving an instance: Error in the network protocol (code 9)

Background: we’re accessing an external application to notify it a new instance has arrived.

In this case the remote application returns a 415 because I wasn’t sending the Content-Type header. I know that it was a 415 because Orthanc was running on verbose mode (HttpClient.cpp line is an Info line). But my plugin (from the PluginsManager.cpp lines) reports a 500, which the default value assigned to the httpStatus variable.

In short, you can reproduce it with a code as follows:

uint16_t httpStatus = 500;
OrthancPluginHttpClient( …, &httpStatus, … ); // remote server will return a 415
// logging outputs 500, not 415

For the remote server, any “nc” with the proper HTTP response headers will do. OrthancPluginErrorCode will be 9, which is the network protocol error, and that is correct, I believe.

Now, I haven’t tested other error codes. But I have no reason to believe it’d be different. Hence this question/post.

If this is indeed confirmed, how should I go about reporting it properly (any JIRA, special e-mail, etc)?

Can I try and fix it myself? I have already created an issue in our company’s own JIRA but it’s set to low priority since it doesn’t affect our plugin that much other than crippling our logs a real tiny bit.



Hello Luiz,

I confirm the issue. Thanks for reporting it!

It is now fixed in the mainline by the following changeset: