-
Notifications
You must be signed in to change notification settings - Fork 105
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 is not encoding the "Content-Type" according to standard #113
Comments
I think this issue is likely inside dicomweb-client, not |
Oh no, it likely is in |
Is there an easy way to replicate this issue? |
Hey @pieper , you can use the public endpoint of DICOMcloud to replicate this with OHIF when saving Measurements via SR. |
@Zaid-Safadi @JamesAPetts This is actually in dicomweb-client/src/api.js. |
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
The text was updated successfully, but these errors were encountered: