Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stow-RS fails with current verion sending to orthanc #42

Closed
HannoGao opened this issue Nov 20, 2020 · 5 comments
Closed

Stow-RS fails with current verion sending to orthanc #42

HannoGao opened this issue Nov 20, 2020 · 5 comments
Assignees
Labels
question Further information is requested

Comments

@HannoGao
Copy link

I have a similar issue as #41 regarding the current version:
I am using this great package to send data to an Orthanc instance. Until version 0.41.2 this works.
For the current version, I get a response code 200 (this is probably an Orthanc mistake), but no data can be found on the Orthanc instance. I tested it with different Orthanc version and with the Ortanc docker container.
e.g. the current version:

docker run -p 4242:4242 -p 8042:8042 --rm jodogne/orthanc-plugins
Here the code snipped to reproduce:

from dicomweb_client.api import DICOMwebClient
from dicomweb_client.session_utils import create_session_from_auth
from requests.auth import HTTPBasicAuth
auth = HTTPBasicAuth('orthanc', 'orthanc')
session = create_session_from_auth(auth)
client = DICOMwebClient(url="http://localhost:8042/dicom-web", session=session)
path = "" # ADD path to a dicom file
dcmfile = pydicom.dcmread(path)
value = client.store_instances([dcmfile])

With version 0.50.3 there is no data anymore on the server:
http://localhost:8042/app/explorer.html#find-patients (login with orthanc/orthanc), there is no error message ...

@hackermd hackermd added the question Further information is requested label Nov 20, 2020
@hackermd hackermd self-assigned this Nov 20, 2020
@hackermd
Copy link
Collaborator

Thanks for reporting the issue @HannoGao. Since version 0.5.0 the client uses chunked transfer encoding for the Store transaction by default. The transfer is part of HTTP 1.1 and according to RFC 2730 every server must support it:

A recipient MUST be able to parse and decode the chunked transfer
coding.

However, orthanc may struggle with handling these messages correctly. What does your server log say?

You can try disabling chunked transfer encoding by choosing a large chunk_size that is guaranteed to be larger than the payloads you are sending. The client will then send everything in one message without chunked transfer encoding.

@HannoGao
Copy link
Author

Thanks for the response.
I tried to increase the chunk_size, but this does not seem to be the problem. I am just trying to send one file with less than 200 kB.
The Orthanc server logs, just show, that it cannot handle the data:
When sending with 0.41.2:

I1123 11:09:29.376022 HttpServer.cpp:1165] POST /dicom-web/studies
I1123 11:09:29.376099 OrthancPlugins.cpp:5127] Delegating chunked HTTP request to plugin for URI: /dicom-web/studies
I1123 11:09:29.376136 PluginsManager.cpp:172] STOW-RS request without study
I1123 11:09:29.380303 OrthancPlugins.cpp:2455] Plugin making REST POST call on URI /instances (built-in API)
I1123 11:09:29.380346 OrthancRestApi.cpp:116] Receiving a DICOM file of 197990 bytes through HTTP
I1123 11:09:29.388075 FilesystemStorage.cpp:107] Creating attachment "db21c413-e473-4219-95e1-b49400d11978" of "DICOM" type (size: 1MB)
I1123 11:09:29.393730 FilesystemStorage.cpp:107] Creating attachment "513d6b4a-a90d-4e08-a277-a4cab03d8f57" of "JSON summary of DICOM" type (size: 1MB)
I1123 11:09:29.397064 ServerContext.cpp:512] New instance stored

With 0.50.3:

I1123 11:11:19.457871 HttpServer.cpp:1165] POST /dicom-web/studies
I1123 11:11:19.457935 OrthancPlugins.cpp:5127] Delegating chunked HTTP request to plugin for URI: /dicom-web/studies
I1123 11:11:19.457970 PluginsManager.cpp:172] STOW-RS request without study

The log just ends there. Orthanc source code seems to not get the data anymore.
So basically I am not sure if this is an Orthanc issue or related to this package.

@hackermd
Copy link
Collaborator

@HannoGao thanks for sharing the logs and providing additional details. Unfortunately, the logs are not really helpful.

I have a suspicion, though. It appears Orthanc doesn't deal with the quotes in the type and boundary fields in the Content-Type header (see RFC 2387 and REF 1341 Section 7.2).

This is how a Content-Type header looks like for a POST request message of the DICOMweb client:

'multipart/related; type="application/dicom"; boundary="0f3cf5c0-70e0-41ef-baef-c6f9f65ec3e1"'

@jodogne
Copy link

jodogne commented Nov 27, 2020

Hello, thanks for the report and for the analysis. This was indeed a bug in the DICOMweb plugin of Orthanc, which has been fixed by the following changeset. The fix will be part of forthcoming release 1.4 of the plugin.

The Docker images of Orthanc have just been updated with this fix, you can give another try with:

$ docker pull jodogne/orthanc-plugins:latest
$ docker run -p 4242:4242 -p 8042:8042 --rm -t -i jodogne/orthanc-plugins:latest

@hackermd
Copy link
Collaborator

Thanks for your feedback @jodogne. Great that this has been fixed in the DICOMweb plugin of Orthanc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants