WadoRS Call is returning Json file though the --accept-type header is application/dicom+xml

[Nusrat]

Hi,

I am using dcm4che-3.3.7 against a dicom server with wado-rs implementaion, Now when i try to retrieve metadata with --accept-type header is applicatrion/dicom+xml, It still returns a Json File instead of an XML file.

D:\dcm4che-3.3.7-bin\dcm4che-3.3.7\bin>wadors --accept-type "type=application/dicom+xml" http://3.204.109.58/ea/AE_ARCH201/studies/1.2.840.6926000.3944820160209

153100928.6.1/metadata --out-dir "D:\output"

Can anybody please let me know if this is an issue with dcm4che ?

Thanks,

Nusrat

[Jouke Numan]

Hi DCM4CHE team,

Issue has been traced to the incorrect value wadors places in the

Accept header field which results in the Accept header being silently

ignored by .NET applications using WCF WebAPI technology.

Because the DICOM Server thinks no Accept header is present, it returns
the default (JSON) format.

wadors sends 'Accept: multipart/related; type=application/dicom+xml' as

the Accept header, which is not valid http, the application/dicom+xml should

be a double quoted string as '/' is a special character.

Correct value is 'Accept: multipart/related; type="application/dicom+xml"'.

This error is still in the examples in the DICOM standard (I'll post that on the

DICOM group), but DICOM2016a added definition of Accept header as part of 

WADO redoc effort and future redoc work will likely correct the examples.

See http://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_6.1.1.1

for definition for Multipart Media Types used in Accept header.

I'll update our DICOM Server implementation to also support wrong format as

this will probably happen with other, non .NET, WADO-RS clients in the spirit

of "send pedantic correct, accept forgivingly" and suggest wadors is updated to

send correct Accept header (might require option to work with all WADO-RS servers).

In the meantime, wadors users and DCM4CHE service providers  should be aware of

this discrepance in Accept header content.

Best Regards.

Jouke Numan

Software Architect

GE Healthcare

PS: Nusrat is on my team, doing integration testing on our DICOM Server.

[Hermann Czedik-Eysenberg]

Hi Jouke,

thanks for reporting that problem!
I opened http://dcm4che.org/jira/browse/LIB-417 and I hope we can fix it soon.

Hermann

[Jouke Numan]

Hi Hermann,

Same has been noticed by us for the boundary parameter in the Content-Type, eg.

    Content-type: multipart/mixed; boundary="boundary"

Will fail also. According to HTTP standards, all parameter values can have quoted strings.

As this affect interoperability of DCM4CHE in DICOMWeb environments, I'd like to impress some

priority/urgency on these issues, eg. previously mentioned issue has still not been fixed.

See https://tools.ietf.org/html/rfc7231#section-3.1.1 for definition of parameters in Media Type and

see https://tools.ietf.org/html/rfc7230#page-27 for definition of token and quoted string

Regards, Jouke

[vrinda...@j4care.com]

You may try using DCM4CHE Version 5.x wadors tool

[Jouke Numan]

Hi vrinda...@j4care.com,

The boundary issue is still in the tool, see boundary method in

https://github.com/dcm4che/dcm4che/blob/master/dcm4che-tool/dcm4che-tool-wadors/src/main/java/org/dcm4che3/tool/wadors/WadoRS.java.

Below statement had to be changed according to the bold and underlined change.

if (s.contains("boundary"))
 boundary = s.substring(s.indexOf("=")+1).replaceAll("\"", "");

Regards, Jouke

[vrinda...@j4care.com]

Thank you for reporting the issue.