FHIR Chat · Retrieving Binary resources

Stream: implementers

Topic: Retrieving Binary resources

Richard Kavanagh (Jun 30 2016 at 11:48):

What is the expected behaviour of retrieving binary resources? I thought that if you did not specify a mimetype the binary content would be returned with the mimetype stored within the binary resource - is that correct?

I created a binary resource here http://spark.furore.com/fhir/Binary/spark160 which is for a PDF file.

I thought that if I did a GET against that URL in a browser I would be returned a PDF file but I don't I get a garbled HTML file.

Not sure whether this is an issue with SPARK or my understanding

Grahame Grieve (Jun 30 2016 at 12:24):

browsers are tricky in this regard. they ask very loosely, and they interpret somewaht idiosyncratically. the first thing to do is to try it in different browsers, and you should also spy in the http traffic and see what the actual return headers say

Josh Mandel (Jun 30 2016 at 15:20):

No, even if I don't supply a content-type I get back application/xml with a Binary resource, instead of the raw PDF:

curl -vvv http://spark.furore.com/fhir/Binary/spark160

< Content-Type: application/xml+fhir; charset=utf-8
< Content-Location: Binary/spark160/_history/spark261
< Expires: -1
< Last-Modified: Thu, 30 Jun 2016 11:38:43 GMT
< ETag: W/"spark261"
< Server: Microsoft-IIS/8.5
< X-AspNet-Version: 4.0.30319
< X-Powered-By: ASP.NET
< Date: Thu, 30 Jun 2016 15:20:23 GMT
< Content-Length: 91866

Josh Mandel (Jun 30 2016 at 15:21):

This goes against the definition:

Binary resources behave slightly differently to all other resources on the RESTful API. Specifically, when a read request is made for the binary resource that doesn't explicitly specify the FHIR content types "application/xml+fhir" or "application/json+fhir", then the content should be returned using the content type stated in the resource. e.g. if the content type in the resource is "application/pdf", then the content should be returned as a PDF directly.

Josh Mandel (Jun 30 2016 at 15:22):

That said, when I do explicitly ask for:

curl -H "Accept: application/pdf" http://spark.furore.com/fhir/Binary/spark160

I indeed get a PDF out. So, Spark is capable of returning the PDF, but is (I think!) doing the wrong thing by default.

Grahame Grieve (Jun 30 2016 at 21:28):

@Ewout Kramer looks like the default behaviour is wrong. I better test my own server

Brian Postlethwaite (Jul 01 2016 at 03:26):

In my server I also include a ContentDisposition header including a filename for the resource with an extension expected for the mimetype. eg application/pdf -> .pdf

Brian Postlethwaite (Jul 01 2016 at 03:26):

Not in the spec, but helps from the browser perspective.

Mirjam Baltus (Jul 01 2016 at 08:08):

I'll raise an issue for Spark to modify this.

John Moehrke (Jul 02 2016 at 16:31):

More evidence to support _format. ... Also, we see Google has had to play special tricks to force web-sites to return html5 rather than Flash; if they are capable, with tricks to support sites that can't... Very much 'accept' is more of a suggestion than an actual interoperability function.

Richard Kavanagh (Oct 02 2018 at 18:39):

My understanding of the Binary resource is that if you perform a "GET" against the resource (with no HTTP Accept headers set) then the response will be the binary object usings its native mime type - is that correct?
I keep looking at various test servers and they return either an XML or JSON Binary resource.

Michael Donnelly (Oct 02 2018 at 18:41):

You're correct, @Richard Kavanagh

Michael Donnelly (Oct 02 2018 at 18:41):

I mean, it's supposed to work the way you think it's supposed to work.

Jenni Syed (Oct 02 2018 at 18:56):

One caution: I know these rules have been clarified as the spec has matured. The latest seems to indicate that there's no hard rule that can be made about the relationship between Accept and what gets returned...