WADO-RS request seems to return response that is incorrectly formatted

Hi All,

When investigating an issue where the wadors utility from DCM4CHE was not able to retrieve from Orthanc server, I discovered
what seems to be incorrectly formatting of the response sent back by Orthanc.

Orthanc terminates the boundary and header lines of a body part with LF character only, whereas standard mandates CR + LF
(see https://tools.ietf.org/html/rfc2046 page 25).

This is tripping up said wadors utility and causes Wireshark to fail re-assembling the response and will probably fail other clients
as well.

Additional observation is that the value of the type parameter in the Content-Type header in the http header is not correct,
this should have been “application/dicom+xml”

Can you confirm that my above observations are correct and maybe give a timeline when this will be solved?

Best Regards,

Jouke Numan
GE Healthcare

Excerpts from wireshark:

Request:

GET /dicom-web/studies/1.2.840.6926000.622420150201223413471.4.1

Response:

First packet (http headers have correct CR+LF termination):

0000 24 be 05 e2 dd bd 00 08 e3 ff ff fc 08 00 45 00 $…E.
0010 00 a3 60 b8 40 00 7c 06 11 d0 03 cc 6d 4a 03 cc [….@.|.....mJ](mailto:...@.|…mJ)…
0020 16 eb 1f 6a da 9c c5 5a a7 96 a2 76 16 c5 50 18 …j…Z…v…P.
0030 02 01 3f 74 00 00 48 54 54 50 2f 31 2e 31 20 32 …?t…HTTP/1.1 2
0040 30 30 20 4f 4b 0d 0a 43 6f 6e 74 65 6e 74 2d 54 00 OK…Content-T
0050 79 70 65 3a 20 6d 75 6c 74 69 70 61 72 74 2f 72 ype: multipart/r
0060 65 6c 61 74 65 64 3b 20 74 79 70 65 3d 6d 75 6c elated; type=mul
0070 74 69 70 61 72 74 2f 72 65 6c 61 74 65 64 3b 20 tipart/related;
0080 62 6f 75 6e 64 61 72 79 3d 36 34 63 34 64 64 63 boundary=64c4ddc
0090 34 2d 34 39 62 38 2d 34 64 31 30 2d 38 38 61 62 4-49b8-4d10-88ab
00a0 2d 61 36 38 38 64 35 30 64 64 38 39 39 0d 0a 0d -a688d50dd899…
00b0 0a .

Second packet (CR is missing at end of boundary line and bodypart header lines (marked red below)):

0000 24 be 05 e2 dd bd 00 08 e3 ff ff fc 08 00 45 00 $…E.
0010 05 dc 60 b9 40 00 7c 06 0c 96 03 cc 6d 4a 03 cc [….@.|.....mJ](mailto:...@.|…mJ)…
0020 16 eb 1f 6a da 9c c5 5a a8 11 a2 76 16 c5 50 10 …j…Z…v…P.
0030 02 01 73 13 00 00 2d 2d 36 34 63 34 64 64 63 34 …s…–64c4ddc4
0040 2d 34 39 62 38 2d 34 64 31 30 2d 38 38 61 62 2d -49b8-4d10-88ab-
0050 61 36 38 38 64 35 30 64 64 38 39 39 0a 43 6f 6e a688d50dd899.Con
0060 74 65 6e 74 2d 54 79 70 65 3a 20 61 70 70 6c 69 tent-Type: appli
0070 63 61 74 69 6f 6e 2f 64 69 63 6f 6d 2b 78 6d 6c cation/dicom+xml
0080 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a .Content-Length:
0090 20 31 33 30 38 35 0a 4d 49 4d 45 2d 56 65 72 73 13085.MIME-Vers
00a0 69 6f 6e 3a 20 31 2e 30 0a 0a 3c 3f 78 6d 6c 20 ion: 1.0…<?xml 00b0 76 65 72 73 69 6f 6e 3d 22 31 2e 30 22 20 65 6e version="1.0" en 00c0 63 6f 64 69 6e 67 3d 22 75 74 66 2d 38 22 3f 3e coding="utf-8"?>
00d0 0a 3c 4e 61 74 69 76 65 44 69 63 6f 6d 4d 6f 64 .<NativeDicomMod
00e0 65 6c 20 78 6d 6c 6e 73 3d 22 68 74 74 70 3a 2f el xmlns="http:/
00f0 2f 64 69 63 6f 6d 2e 6e 65 6d 61 2e 6f 72 67 2f /dicom.nema.org/

Hello,

Thanks for pointing out these problems.

The “CR + LF” is now fixed in the mainline of the Orthanc core, with the following change:
https://bitbucket.org/sjodogne/orthanc/commits/b7da58699f929efcdde60697f712a992639960a8

Would it be possible for you to give a hit by recompiling the Orthanc core?

I will look at the other problem about “Content-Type” in the following days.

Regards,
Sébastien-

Hi,

OrthanC server is failing to start with the latest core , Please find below the log:

W1130 12:01:40.169108 main.cpp:1101] Orthanc version: mainline

W1130 12:01:40.172109 OrthancInitialization.cpp:128] Reading the configuration from: “Configuration.json”

W1130 12:01:40.176109 HttpClient.cpp:386] No certificates are provided to validate peers, set “HttpsCACertificates” if you need to do HTTPS requests

W1130 12:01:40.179109 FromDcmtkBridge.cpp:200] Loading the embedded dictionaries

W1130 12:01:40.376129 OrthancInitialization.cpp:399] Registering JPEG Lossless codecs

W1130 12:01:40.376129 OrthancInitialization.cpp:404] Registering JPEG codecs

W1130 12:01:40.622154 main.cpp:618] Loading plugin(s) from: OrthancDicomWeb-0.1.dll

W1130 12:01:40.676159 PluginsManager.cpp:264] Registering plugin ‘dicom-web’ (version 0.1)

W1130 12:01:40.678159 PluginsManager.cpp:167] URI to the DICOMweb REST API: /dicom-web/

W1130 12:01:40.681160 PluginsManager.cpp:167] URI to the WADO API: /wado

W1130 12:01:40.681160 OrthancInitialization.cpp:885] SQLite index directory: “OrthancStorage”

W1130 12:01:40.683160 OrthancInitialization.cpp:955] Storage directory: “OrthancStorage”

E1130 12:01:40.687160 main.cpp:829] The database schema must be upgraded from version 5 to 6: Please run Orthanc with the “–upgrade” command-line option

W1130 12:01:40.688160 PluginsManager.cpp:214] Unregistering plugin ‘dicom-web’ (version 0.1)

W1130 12:01:40.695161 main.cpp:1173] Orthanc has stopped

Please let us know the detailed steps to upgrade db schema from version 5 to version6.

Thanks,
Nusrat

You can upgrade the database by running: orthanc.exe “path to configuration.json” --upgrade

Regards,
Robert

Hello,

The secondly reported problem (about incorrect Content-Type in the HTTP header in multipart answers) is fixed:
https://bitbucket.org/sjodogne/orthanc/commits/aa95aea0a352b2b642946ae20ef5bda92caa025c

This was also an issue within the Orthanc core (and not in the DICOMweb plugin).

New official release 0.9.5 with the two fixes included should hopefully be available tomorrow.

Regards,
Sébastien-

Hi Sebastien,

Could you please share the OrthanC exe which has the fix for incorrect content-type , so that we can use it until 0.9.5 is released.

Thanks,
Nusrat

0.9.5 will be out in the next few hours.