STOW-RS is not encoding the "Content-Type" according to standard

[Zaid-Safadi]

trafficstars

In OHIF viewer the store measurements is failing when storing to DICOMlcoud server. see this issue for reference.

I traced this and it is caused by the server not recognizing the "Content-Type" header ( Built-in .NET library) because it is not not formatted properly.

For STOW-RS, the Content-Type is being sent as: Content-Type: multipart/related; type=application/dicom; boundary=2afeebaf-038d-792a-f952-d8e249ba8e96

The correct format should be: Content-Type: multipart/related; type="application/dicom"; boundary="2afeebaf-038d-792a-f952-d8e249ba8e96"

Notice the "Quotation mark" around the type and boundary parameters: type="application/dicom"

This used to be a bug in the DICOM standard when DICOMweb was initially released but then they corrected it to match the HTTP RFC specs: I think this is the new reference: http://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_8.7.3.5.1 and https://tools.ietf.org/html/rfc2387

[JamesAPetts]

I think this issue is likely inside dicomweb-client, not dcmjs?

[JamesAPetts]

Oh no, it likely is in dcmjs, my mistake.

[pieper]

Is there an easy way to replicate this issue?

[Zaid-Safadi]

Hey @pieper , you can use the public endpoint of DICOMcloud to replicate this with OHIF when saving Measurements via SR. http://dicomcloud.azurewebsites.net/api/studies

[Dev-Now]

@Zaid-Safadi @JamesAPetts This is actually in dicomweb-client/src/api.js. I need this fixed.