Viewers: Unable to load studies from Orthanc...getting "Cross-Origin Request Blocked" errors

[ranasrule]

On the latest build Im unable to load studies from Orthanc...The browser console shows a bunch of "Cross-Origin Request Blocked" errors. The last build I complied was from about a month back and it works just fine.

[dannyrb]

The resource you are requesting is at the same IP/domain, but a different port. Unless you have something in place to set the appropriate CORS headers, this will happen.

What are the steps to reproduce? Can you identify a version where this worked, and then the one where it stopped working?

[ranasrule]

The resource you are requesting is at the same IP/domain, but a different port. Unless you have something in place to set the appropriate CORS headers, this will happen.

What are the steps to reproduce? Can you identify a version where this worked, and then the one where it stopped working?

I'm getting the issue weather the study is loaded from the study list or via a direct url. The last build I have that is working correctly is 3.4.1 and the first build Im experiencing the issue on is 3.8.14

[dannyrb]

What are your steps to reproduce? Are you using the built in docker orthanc command?

[ranasrule]

What are your steps to reproduce? Are you using the built in docker orthanc command?

I'm building from source and then serving via nginx

[dannyrb]

What does your nginx configuration look like?

[ranasrule]

What does your nginx configuration look like?

nginx.txt

[ranasrule]

What does your nginx configuration look like?

did you find anything in the ngix config file @dannyrb ?

[ranasrule]

@dannyrb I dont understand why OHIF is accessing http://localhost/dicom-web/ in the attached screenshot. Shouldn't it be trying to access http://localhost:8042/dicom-web/ ?

[ranasrule]

ok now this is getting weird....some studies are loading just fine(see screenshot)...some partially and other not at all(screenshots already provided)

[dannyrb]

It's possible 404 or 500 level requests are not appending CORS headers; obfuscating the underlying issue.

[ranasrule]

It's possible 404 or 500 level requests are not appending CORS headers; obfuscating the underlying issue.

any idea where the issue is? viewer? nginx config?

[ranasrule]

@dannyrb I dont understand why OHIF is accessing http://localhost/dicom-web/ in the attached screenshot. Shouldn't it be trying to access http://localhost:8042/dicom-web/ ?

@dannyrb this is the thing I'm noticing in all the studies that are failing to load

[dannyrb]

What does your appConfig look like? How about your series and instance metadata calls?

I'm not sure why you would sometimes hit the route with the port, and other times not. I know some requests are based off location information provided in the metadata.

[ranasrule]

@dannyrb thank you again for your reply. I have attached my app-config.js file and console log. How do I get series and instance metadata calls(is the attached screenshot sufficent)?

localhost-1587780345480.log

app-config.txt

[dannyrb]

Does your issue resolve if you modify your appConfig's dicomweb endpoints to use absolute URLs instead of relative URLs?

[ranasrule]

Does your issue resolve if you modify your appConfig's dicomweb endpoints to use absolute URLs instead of relative URLs?

no it doesn't.

[ranasrule]

@dannyrb Its just crazy....the older build with the exact same config works fine but the latest one dont. Could it have something to do with the recent metadata overhaul in the 3.7.8+ builds?

[ranasrule]

@dannyrb I just built 3.7.7(as metadata overhaul is in the 3.7.8+ builds) from source and it works fine.

[dannyrb]

It's possible, I guess. Its just very odd that this is an intermittent issue depending on the study. I'm not sure I can diagnose further without a docker image or similar reproduction.

I am aware of several larger orgs that are using a post-metadata overhaul version without issue.

[ranasrule]

It's possible, I guess. Its just very odd that this is an intermittent issue depending on the study. I'm not sure I can diagnose further without a docker image or similar reproduction.

I am aware of several larger orgs that are using a post-metadata overhaul version without issue.

@dannyrb is there anything I can do to help you diagnose the issue? Would it help if I shared a few instances of the studies(or the whole study) causing the issue at my end?

[salimkanoun]

@ranasrule , @dannyrb
This issue is related to something i pointed few days ago : https://github.com/OHIF/Viewers/issues/1602

This problem is related to the bulk/60003000 Route for DICOMWeb while the other route /instance is OK. (look at your screen capture the failing one are /6003000)
This is due to a difference of URI origin interpretation, the bulk/60003000 is taking the URI from dicomweb while the /instance route don't.

Also this route did not benefit of the speed first rendering improvement that was done recently (see https://github.com/OHIF/Viewers/issues/1536)

I think this route still suffers from some inconsistancy compared to the /instance API,

Best regards,

Salim

[ranasrule]

@ranasrule , @dannyrb
This issue is related to something i pointed few days ago : #1602

This problem is related to the bulk/60003000 Route for DICOMWeb while the other route /instance is OK. (look at your screen capture the failing one are /6003000)
This is due to a difference of URI origin interpretation, the bulk/60003000 is taking the URI from dicomweb while the /instance route don't.

Also this route did not benefit of the speed first rendering improvement that was done recently (see #1536)

I think this route still suffers from some inconsistancy compared to the /instance API,

Best regards,

Salim

@salimkanoun thanks for your reply. So this is a known issue?

[salimkanoun]

Partial issue,

If you configer properly the Host parameter of dicom web plugin of orthanc
you will fly.

The partial issue is that OHIF have different server identification for
these two routes making this problem more difficult to identify

Le dim. 26 avr. 2020 à 01:08, Rana Asim Wajid [e-mail] a
écrit :

@ranasrule https://github.com/ranasrule , @dannyrb
https://github.com/dannyrb
This issue is related to something i pointed few days ago : #1602
https://github.com/OHIF/Viewers/issues/1602

This problem is related to the bulk/60003000 Route for DICOMWeb while the
other route /instance is OK. (look at your screen capture the failing one
are /6003000)
This is due to a difference of URI origin interpretation, the
bulk/60003000 is taking the URI from dicomweb while the /instance route
don't.

Also this route did not benefit of the speed first rendering improvement
that was done recently (see #1536
https://github.com/OHIF/Viewers/issues/1536)

I think this route still suffers from some inconsistancy compared to the
/instance API,

Best regards,

Salim

@salimkanoun https://github.com/salimkanoun thanks for your reply. So
this is a known issue?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OHIF/Viewers/issues/1665#issuecomment-619452539, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AGAPT7RHOIDZDYXPDT6MYRTRONUOPANCNFSM4MPG5XLQ
.

[ranasrule]

Partial issue, If you configer properly the Host parameter of dicom web plugin of orthanc you will fly. The partial issue is that OHIF have different server identification for these two routes making this problem more difficult to identify Le dim. 26 avr. 2020 > .

@salimkanoun can you please guide me regarding how to as you said "configure properly the Host parameter of dicom web plugin of orthanc" ?

[salimkanoun]

in the dicomWeb plugin of Orthanc you have a "host" parameter, this should
have the value of your server address this way the BulkDataURI sent by
orthanc will have the correct value
The other way if you are using a reverse proxy is to give the host value
using Forwarded or Host http header

https://book.orthanc-server.com/plugins/dicomweb.html
https://groups.google.com/forum/#!topic/orthanc-users/DOp8mzaW18c

Le dim. 26 avr. 2020 à 01:15, Rana Asim Wajid [e-mail] a
écrit :

Partial issue, If you configer properly the Host parameter of dicom web
plugin of orthanc you will fly. The partial issue is that OHIF have
different server identification for these two routes making this problem
more difficult to identify Le dim. 26 avr. 2020 à 01:08, Rana Asim Wajid
[email protected] a écrit :
… <#m_-8237255031458664074_>
@ranasrule https://github.com/ranasrule https://github.com/ranasrule ,
@dannyrb https://github.com/dannyrb https://github.com/dannyrb This
issue is related to something i pointed few days ago : #1602
https://github.com/OHIF/Viewers/issues/1602 <#1602
https://github.com/OHIF/Viewers/issues/1602> This problem is related to
the bulk/60003000 Route for DICOMWeb while the other route /instance is OK.
(look at your screen capture the failing one are /6003000) This is due to a
difference of URI origin interpretation, the bulk/60003000 is taking the
URI from dicomweb while the /instance route don't. Also this route did not
benefit of the speed first rendering improvement that was done recently
(see #1536 https://github.com/OHIF/Viewers/issues/1536 <#1536
https://github.com/OHIF/Viewers/issues/1536>) I think this route still
suffers from some inconsistancy compared to the /instance API, Best
regards, Salim @salimkanoun https://github.com/salimkanoun
https://github.com/salimkanoun thanks for your reply. So this is a known
issue? — You are receiving this because you were mentioned. Reply to this
email directly, view it on GitHub <#1665 (comment)
https://github.com/OHIF/Viewers/issues/1665#issuecomment-619452539>, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AGAPT7RHOIDZDYXPDT6MYRTRONUOPANCNFSM4MPG5XLQ
.

can you please guide me regarding how to as you said "configure properly
the Host parameter of dicom web plugin of orthanc" ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OHIF/Viewers/issues/1665#issuecomment-619453175, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AGAPT7TNTNGGCVQPJUZZBJ3RONVH7ANCNFSM4MPG5XLQ
.

[ranasrule]

in the dicomWeb plugin of Orthanc you have a "host" parameter, this should have the value of your server address this way the BulkDataURI sent by orthanc will have the correct value The other way if you are using a reverse proxy is to give the host value using Forwarded or Host http header https://book.orthanc-server.com/plugins/dicomweb.html https://groups.google.com/forum/#!topic/orthanc-users/DOp8mzaW18c Le dim. 26 avr. 2020 à 01:15, Rana Asim Wajid [e-mail] a écrit :

@salimkanoun Im using a reverse proxy in Nginx. My config file is attached. Can you please show me how to give the host value using Forwarded or Host http header? Ive been pulling my hair out trying to get this to work for the last two days.

What I cant figure out is why all bulk/60003000 requests are directed to "localhost:80" and all others correctly go correctly to http://:8099/orthanc/

nginx.txt

[ranasrule]

@dannyrb @salimkanoun

Well now things are getting even weirder. Using the attached Nginx config file I'm able to open all studies including bulk/60003000 request ones BUT only as long as I'm accessing OHIF from localhost. When I try to access from another node over the network or the internet all bulk/60003000 requests are directed to "localhost:80"....does this make any sense to you guys?

nginx.txt

[salimkanoun]

look my PHP reverse proxy

https://github.com/salimkanoun/GaelO/blob/master/src/scripts/dicom_web.php
line 69

[ranasrule]

@salimkanoun

Ok I think I just fixed it (fingers crossed). In the Orthanc dicomweb.json config file I deleted the "Host" parameter....and that fixed everything. Is there any downside to doing this?

[salimkanoun]

@ranasrule , no that is the good way, this host parameter is deprecated, the informations should come from your reverse proxy http header like i did in PHP

[ranasrule]

@ranasrule , no that is the good way, this host parameter is deprecated, the informations should come from your reverse proxy http header like i did in PHP

Thanks a bunch for all your help @salimkanoun . Jazakallah.