[Bug] PDFs Won't Load From DCM4CHEE

[Michael-Andersen]

Describe the Bug

If I don't specify "pdf" in "singlepart" field of config then when trying to load a pdf I get a 406 Not Accepted Error. The request url is bulkdata and the accept header being sent is multi-part/related type: application/octet-stream. If I recreate the request in postman I get this response {"errorMessage":"Not accepted instances present."}, however if I used multi-part/related type: application/pdf in postman, I get a 200 response. It doesn't seem like dicomweb-client bulkdata requests ever use that header though?

If instead I specify "pdf" in "singlepart" instead a rendered endpoint is passed to the Object element and the pdf still fails to load. If I hit this rendered endpoint in postman I also get a 200 response. I don't see an actual request being made to the rendered endpoint in dev tools though.

We are using DCM4CHEE 31.1.

Steps to Reproduce

1. Choose one of the config options above.
2. Double click DOC modality pdf series.

The current behavior

"No online PDF viewer installed"

The expected behavior

PDF loads.

OS

Windows 10

Node version

16.17.0

Browser

119.0.6045.160

[Michael-Andersen]

Confirmed that if I make changes to dicomweb-client to send multi-part/related type: application/pdf for bulkdata requests then it works. It seems DCM4CHEE doesn't support application/octet-stream for this endpoint. So I suppose this requires a PR in the dicomweb-client repo but for now I have workaround.

Worth noting for others, the pdfs never seem to load if I have the developer tools open in Chrome.

[sedghi]

related issue #3837

[sedghi]

Hey @wayfarer3130, I genuinely believe it would be great if we could switch back to using pdf.js for the PDF, similar to how v2 handled PDF. It's clear that there have been frequent reports of significant server compatibility issues lately. I'd love to hear your thoughts on this.

[wenchaotao]

Hi Michael,

Can you elaborate on the workaround that you have for this issue? I am experiencing the same problem with my OHIF+DCM4CHEE setup. Thanks.

[wayfarer3130]

I understand what the issue is - switching to pdf.js wouldn't help at all, since the issue is fetching the data correctly, not displaying it correctly. The behaviour should be:

1. If specified using InlineBinary, decode the InlineBinary directly and display direct
2. If singlepart retrieve is configured in the configuration, then use the specified pdf endpoint for retrieving the data (typically /rendered using accept application/pdf as specified in the DICOMweb standard)
3. Otherwise, use the BulkDataURI with multipart/related; content-type=application/octet-stream

That isn't a hard fix now that I see what the workaround is above. Will try to get to that shortly.

[sedghi]

@wayfarer3130 I proposed pdf.js since v2 used that

[Michael-Andersen]

Hi Michael,

Can you elaborate on the workaround that you have for this issue? I am experiencing the same problem with my OHIF+DCM4CHEE setup. Thanks.

I have a local copy of dicomweb-client where I've changed line 741 of api.js: https://github.com/dcmjs-org/dicomweb-client/blob/master/src/api.js from 'application/octet-stream' to 'application/pdf'. Then I force the viewer to use my local copy of dicomweb-client by updating package.json to use my local copy of dicomweb-client. Relevant part of my config:

singlepart: 'bulkdata,video', bulkDataURI: { enabled: true, relativeResolution: 'studies', }, omitQuotationForMultipartRequest: true, useBulkDataURI: false,

It sounds like wayfarer3130 has a fix that doesn't require changing dicomweb-client though.