Question about CivetWeb Server in Orthanc, hosting OHIF?

General
1

I was experimenting around a little with various viewers. OHIF is a little tricky to integrate sometimes if one has various reverse proxies already configured, and there are sometimes CORS issues as well.

I am just curious if anyone has tried hosting the OHIF package using the ServerFolders feature within Orthanc. I tried that using the localhost setup with a URL like:

http://localhost:8042/OHIF/index.html/?StudyInstanceUID

and it at least loads the page, but I get an error loading the “workbox-window.dev.mjs” file. The MIME type says “application/octet-stream”, but I think it should be “application/javascript” ?

“Loading module from “http://localhost:8042/OHIF/third_party/workbox/workbox-v5.1.4/workbox-window.dev.mjs” was blocked because of a disallowed MIME type (“application/octet-stream”).”

I also get an error:

Sorry, this page does not exist.
Go back to the Study List

and after clicking on that I see the study list, and then when I click on a study it does actually display in OHIF, with no other apparent errors.

The performance isn’t bad in my dev setup. The OHIF package was built with npm and yarn from the GitHub repo and then the dist folder is mapped to a ServeFolders folder.

Just wondering how feasible it is to host OHIF that way ? Does CivetWeb have a config for MIME types for the .mjs and .js files ? Can it handle Cookies and ENV variables somehow. I presume that the Civet web server is also used for Explorer2, Stone, etc.

Might be that these are not included because it is embedded and not standalone ?

src/third_party/* (third party components, mainly used for the standalone server)
src/mod_*.inl (modules to access third party components from civetweb)

One other issues I’ve noted with OHIF is that multipage embedded PDF’s do not scroll to the “last page”, but when they are downloaded the whole document downloads. That might be an OHIF issue or related to the format of the embedded PDF.

Stephen D. Scotti

1 Like
2

Read the manual: Sample Serve Folders plugin — Orthanc Book documentation

https://book.orthanc-server.com/plugins/serve-folders.html

This seems to have fixed the issue with the MIME type for the .mjs file, but I still get the error message asking me to proceed to the study list. Progress though. I guess maybe just some config adjustments for now.

    "ServeFolders": {
    "AllowCache" : false,
    "GenerateETag" : false,
    "Extensions": {
      ".mjs": "application/javascript"
    },
    "Folders" : {
    "/docs": "/development/Sphinx",
    "/custom": "/development/custom",
    "/OHIF": "/OHIF/Viewers-master/platform/viewer/dist"
    }
  }
3

A follow up about my original question. With:

"/OHIF": "/OHIF/Viewers-master/platform/viewer/dist" or
"/viewer": "/viewer/Viewers-master/platform/viewer/dist"

The URL: http://localhost:8042/OHIF / http://localhost:8042/viewer

gives a 404 error when /index.html is not included, but it does load if I add that and then OHIF at least partially works this way, which would be nice for development purposes.

Is there are way to configure ServeFolders so that the server will ‘look’ for index.html if there is a 404, similar to what NGINX does with: try_files $uri /index.html?url=$uri&$args;

4

No, this is not possible right now. But you could easily create a Python plugin to this end.

5

**Right, I was looking into that. What callback would I use ? if I somehow wanted to ‘simulate’ that NGINX behavior for the try files? ** I guess I would need to interecept ServerFolders urls and ‘edit’ them in certain cases, or just pass them through in others.

I am a C++ novice.

https://hg.orthanc-server.com/orthanc/file/default/OrthancServer/Plugins/Samples/ServeFolders/Plugin.cpp

ServeFolders/Plugin.cpp

could add that and maybe some others, although you can do through the orthanc.json config dynamically.

extensions_[“mjs”] =“application/javascript”;

It is interesting because I now have OHIF sort of embedded in an Orthanc instance by just doing a ‘yarn build’ of the downloaded source in a Dockerfile and then mapping the dist folder to a ServeFolders URL mapped to the dist folder in the container. That way there is no need for the NGINX reverse proxy and it is the same FQDN. Easy to develop on also.

Not sure how that will work if my Orthanc instance is behind of reverse proxy, but I guess I’ll find out.

6

Why do you want to use C++ if you are not familiar with this language, while you can implement this using Python plugins? The latter can also extend the REST API of Orthanc to achieve the same goal as the ServeFolders plugin.

7

Working on it. Apparently this is the best branch for OHIF: Viewers-3-stable.zip

8

Hey any update on your progress ?

9

Not really that feasible.

although I think I’ve been able to integrate the standard package (i.e the Osimis BitBucket setup) with some adjustments to the nginx.conf config such that it can run via a TLS connection without running into the SharedArray Buffer issue that I was encountering previously.

OHIF would work fine for me previously if I ran it on localhost, but it would throw the SharedArray Buffer error and some other errors if I used a FQDN.

I think you need to have a TLS connection for that to work, and you need to get past the CORS issue. I posted something recently about that in another post.

See: OHIF integration

10

Hello,

The newly released OHIF plugin for Orthanc precisely uses the CivetWeb server that is embedded inside Orthanc to host OHIF: https://discourse.orthanc-server.org/t/new-plugin-ohif/

Best Regards,
Sébastien-

1 Like