As shown in the picture:

Each interface URL points to 'qidors'. I thick it's unsafe in the runtime.
Are you experiencing any issues? (Failing requests in the app)
What does your app configuration file look like? Do you see the same values when using the default configuration file?
I have find the reasons. It is caused by incorrect use of dicomweb-client. Line in 'Viewers-master\platform\core\src\studies\services\wado\retrieveMetadataLoaderAsync.js', should be modified as follows:
export default class RetrieveMetadataLoaderAsync extends RetrieveMetadataLoader {
configLoad() {
const { server } = this;
var options = {
url: server.baseUrl,
headers: DICOMWeb.getAuthorizationHeader(server),
qidoURLPrefix: server.qidoURLPrefix,
wadoURLPrefix: server.wadoURLPrefix,
};
const client = new api.DICOMwebClient(options);
this.client = client;
}
the value of 'options' should contain qidoURLPrefix and wadoURLPrefix, even stowURLPrefix. If not, the same values will be assigned to qidoURL, wadoURL and stowURL in dicomweb-client through else statement. The relevant code in dicomweb-client as follow:
if ('qidoURLPrefix' in options) {
console.log("use URL prefix for QIDO-RS: ".concat(options.qidoURLPrefix));
this.qidoURL = this.baseURL + '/' + options.qidoURLPrefix;
} else {
this.qidoURL = this.baseURL;
}
if ('wadoURLPrefix' in options) {
console.log("use URL prefix for WADO-RS: ".concat(options.wadoURLPrefix));
this.wadoURL = this.baseURL + '/' + options.wadoURLPrefix;
} else {
this.wadoURL = this.baseURL;
}
if ('stowURLPrefix' in options) {
console.log("use URL prefix for STOW-RS: ".concat(options.stowURLPrefix));
this.stowURL = this.baseURL + '/' + options.stowURLPrefix;
} else {
this.stowURL = this.baseURL;
}
@dannyrb, Do you have read my problem solving code ?
馃憢 Hi @JiangWeian, sorry for the delay. On my list. I'll either give it a read tomorrow (11/14), or make sure it's assigned to an appropriate individual.
@JiangWeian I think you are correct and that your fix makes sense.
The way RetrieveMetadataLoaderAsync is currently implemented it will only function correctly against PACS which have identical QIDO and WADO endpoints. In the real world this is not always the case. https://github.com/DICOMcloud/DICOMcloud is one example which uses different endpoints, though @Zaid-Safadi says he plans on changing that.
We should set the correct values so they can be used by dicomweb-client here https://github.com/dcmjs-org/dicomweb-client/blob/master/src/api.js#L53
@swederik, then should I pull request?
Sure! That would be great!
DICOMcloud is updated to share the same base URL.
Here is the updated swagger: http://dicomcloud.azurewebsites.net/swagger/
The old URLs are also still supported, so these two are the same:
http://dicomcloud.azurewebsites.net/qidors/studies
http://dicomcloud.azurewebsites.net/api/studies
Guidance/Discussion provided in PR https://github.com/OHIF/Viewers/pull/1175
We specify:
Can we safely say the base is _always_ the same? Or should we ditch "prefix" and "base" and simply always use the Root key values? Then add deprecation warnings for the other keys until the next major bump.
Most helpful comment
DICOMcloud is updated to share the same base URL.
Here is the updated swagger: http://dicomcloud.azurewebsites.net/swagger/
The old URLs are also still supported, so these two are the same:
http://dicomcloud.azurewebsites.net/qidors/studies
http://dicomcloud.azurewebsites.net/api/studies