Bad request headers when connecting OHIF Viewer to Orthanc

Hello,

I am trying to connect OHIF Viewer to an Orthanc instance using the DicomWeb plugin, and I am getting Bad Request errors when trying to view a study in the OHIF Viewer.

Both OHIF and Orthanc are running in Docker containers, and because of CORS, I’m proxying all requests to Orthanc via nginx running in the OHIF container, adding necessary CORS headers. This fixed my initial problem that OHIF couldn’t get a list of studies from Orthanc. That is now working. But when I’m trying to view a specific study, it’s broken.

Orthanc is returning 400 Bad Request response to OPTIONS requests like:
OPTIONS /dicom-web/studies/61.7.268394637588031297898846873298459800625/series/61.7.266462757557857156201957313613544785133/instances/61.7.261206463739157987070113584621540452227/frames/1

This is an example failing request:

OPTIONS /dicom-web/studies/61.7.268394637588031297898846873298459800625/series/61.7.266462757557857156201957313613544785133/instances/61.7.261206463739157987070113584621540452227/frames/1 HTTP/1.1
Host: xxx.yyy.zzz.xxx:9842
Connection: keep-alive
Accept: /
Access-Control-Request-Method: GET
Access-Control-Request-Headers: accept
Origin: http://xxx.yyy.zzz.xxx
Sec-Fetch-Mode: cors
Referer: http://xxx.yyy.zzz.xxx/viewer/61.7.268394637588031297898846873298459800625
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,cs;q=0.8

(The IP addreses have been redacted.)

Same thing happens when using curl with or without the above headers, both when sending the request directly and through the nginx proxy:

curl ‘http://xxx.yyy.zzz.xxx:8042/dicom-web/studies/61.7.268394637588031297898846873298459800625/series/61.7.266462757557857156201957313613544785133/instances/61.7.261206463739157987070113584621540452227/frames/1’ -X ‘OPTIONS’ -v

  • Trying xxx.yyy.zzz.xxx:8042…
  • Connected to xxx.yyy.zzz.xxx (xxx.yyy.zzz.xxx) port 8042 (#0)

OPTIONS /dicom-web/studies/61.7.268394637588031297898846873298459800625/series/61.7.266462757557857156201957313613544785133/instances/61.7.261206463739157987070113584621540452227/frames/1 HTTP/1.1
Host: xxx.yyy.zzz.xxx:8042
User-Agent: curl/7.70.0
Accept: /

  • Mark bundle as not supporting multiuse
    < HTTP/1.1 400 Bad Request
    < Connection: keep-alive
    < Content-Length: 0

When I try out the same request using GET method, everything is ok and data is received fine, but for some reason the OPTIONS requests are failing.

Can anyone help me with this? I don’t see any error in the Orthanc output and there is no log file that i could find, so I’m a bit lost.

Just FYI, Orthanc is using the jodogne/orthanc-plugins:1.7.1 Docker image, and OHIF Viewer is version 4.2.5.

Best regards

Ondra M.

Hello,

Aha, ok. So I should be able to bypass this by simply answering 200 to OPTIONS requests in the nginx proxy instead of letting them pass through to Orthanc. Or something like that.

Or maybe, is there a way to use nginx or Apache instead of the builtin web server with Orthanc?

Dne út 7. čvc 2020 6:33 uživatel Sébastien Jodogne <s.jodogne@gmail.com> napsal:

Hi Ondra,

This link contains a link to a Nginx Cors config https://book.orthanc-server.com/faq/same-origin.html

James

Binary Logo

James Manners • Director
Suite 3, Level 2, 10 Queens Road, Melbourne, Victoria 3004, Australia

T: 03 9017 5230 M: 0422 973 235 E: james@binary.com.au W: binary.com.au

Thanks James, but I already read that and that didn’t really give me any new info.

I fixed the problem by proxying Orthanc via the nginx proxy on the same port like OHIF, just under an /ort/ subroute. Before, it was proxied via a different port, which meant different origin, which meant that CORS came into play and OHIF was sending the OPTIONS requests, which were failing. Now, when it’s under the same port, it’s considered same origin and OHIF only sends GET requests which work fine.

Thanks for help guys.

Best regards

Ondra M.

Dne úterý 7. července 2020 12:43:57 UTC+2 James Manners napsal(a):