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

Dicom upload to dcm4chee no longer works #3497

Closed
jbocce opened this issue Jun 27, 2023 · 12 comments
Closed

Dicom upload to dcm4chee no longer works #3497

jbocce opened this issue Jun 27, 2023 · 12 comments
Labels
Bug Verified Bug reported, reproducible, and verified.

Comments

@jbocce
Copy link
Contributor

jbocce commented Jun 27, 2023

Describe the Bug

Every attempt to upload DICOM using OHIF's DICOM uploader fails when using dcm4chee as a destination.

The suspect PR and commit that MIGHT have caused this is #3406 / 52f419d. The commit prior (3503e6e) to that PR has upload to dcm4chee working fine.

Upload to Orthanc appears to be working fine.

FYI @salimkanoun and @sedghi.

Steps to Reproduce

  1. Run a local instance of OHIF using config/local_dcm4chee.js as the configuration. Be sure to also be running a compatible local dcm4chee instance as is configured in config/local_dcm4chee.js.
  2. Attempt to upload ANY dicom file.

The current behavior

Upload fails...

image

In the browser console and network tabs there are 406 errors/response codes for the upload XHRs...

image

image

image

The expected behavior

The dicom file uploads and can be subsequently viewed in OHIF.

OS

Windows 11

Node version

16.14.0

Browser

Chrome 114.0.5735.134

@jbocce jbocce added Awaiting Reproduction Can we reproduce the reported bug? Bug Verified Bug reported, reproducible, and verified. and removed Awaiting Reproduction Can we reproduce the reported bug? labels Jun 27, 2023
@salimkanoun
Copy link
Contributor

Hi did you updated you config to put the omit quotation parameter in the server level and not global parameter?

@salimkanoun
Copy link
Contributor

Hum I think I have a better explanation the accept header is probably wrong as I guess the api will simply confirm dicom storage and not return the dicom storage.

@salimkanoun
Copy link
Contributor

Could you show the request details before my commit ?

@salimkanoun
Copy link
Contributor

salimkanoun commented Jun 27, 2023

@jbocce could you try changing the line 248

wadoDicomWebClient.headers = generateWadoHeader();

wadoDicomWebClient.headers = generateWadoHeader();
to wadoDicomWebClient.headers = getAuthrorizationHeader();

This will remove the Accept header in the store request and might solve your problem
(don't have a DCM4CHEE server to reproduce the issue)

@jbocce
Copy link
Contributor Author

jbocce commented Jun 27, 2023

Could you show the request details before my commit ?

Thanks @salimkanoun for your quick reply. Here are the request headers prior to your commit...

POST /dcm4chee-arc/aets/DCM4CHEE/rs/studies HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 118079
Content-Type: multipart/related; type="application/dicom"; boundary="480d505f-a2d4-2eb2-aa75-e662b811b20e"
Host: localhost:8080
Origin: http://localhost:3000
Pragma: no-cache
Referer: http://localhost:3000/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
sec-ch-ua: "Not.A/Brand";v="8", "Chromium";v="114", "Google Chrome";v="114"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"

@jbocce
Copy link
Contributor Author

jbocce commented Jun 27, 2023

@jbocce could you try changing the line 248

wadoDicomWebClient.headers = generateWadoHeader();

wadoDicomWebClient.headers = generateWadoHeader(); to wadoDicomWebClient.headers = getAuthrorizationHeader();

This will remove the Accept header in the store request and might solve your problem (don't have a DCM4CHEE server to reproduce the issue)

@salimkanoun, that appears to fix it. Would you say this is the correct solution?

@salimkanoun
Copy link
Contributor

salimkanoun commented Jun 27, 2023

Yes absolutly, see the Accept header of the request :
Previously you had */*
and after my PR you had multipart/related, application/octet-stream

This was an error, as you are sending a dicom you Content is a multipart/related octect stream but the response is probably a simple 201 Created with no content , we are not expecting any particular data from the server at dicom creation.

So yes the fix is the good one

@jbocce
Copy link
Contributor Author

jbocce commented Jun 27, 2023

Yes absolutly, see the Accept header of the request : Previously you had / and after my PR you had multipart/related, application/octet-stream

This was an error, as you are sending a dicom you Content is a multipart/related octect stream but the response is probably a simple 201 Created with no content , we are not expecting any particular data from the server at dicom creation.

So yes the fix is the good one

Thank you so kindly. I will start a PR soon.

@salimkanoun
Copy link
Contributor

my regression my fault ^^

@jbocce
Copy link
Contributor Author

jbocce commented Jun 27, 2023

no worries, forget about it! 😊

@sedghi
Copy link
Member

sedghi commented Aug 16, 2023

what is the status for this?

@salimkanoun
Copy link
Contributor

Should be fixed I guess

@sedghi sedghi closed this as completed Oct 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Verified Bug reported, reproducible, and verified.
Projects
None yet
Development

No branches or pull requests

3 participants