Stream: Touchstone
Topic: Response 'Content-Type' header contains charset=utf-8
Abbie Watson (May 04 2017 at 03:57):
Hi,
Since 3.0.0 tests were deployed, all of our core resources such as Patient and Practitioner have started failing, because they're expecting a content-type of 'application/fhir+json; charset=utf-8;'. Unfortunately, it appears this change is not compliant with IETF RFC 4627 or RFC 2616, and the request.js library doesn't support such encodings (used by express.js, meteor.js, and most other Node based servers). Can we revert back to only testing for a Content-type of 'application/fhir+json?`
https://github.com/request/request/issues/383
https://tools.ietf.org/html/rfc4627
https://tools.ietf.org/html/rfc2616
Screen-Shot-2017-05-03-at-10.52.24-PM.png
Jim Steel (May 04 2017 at 06:58):
We would be against this change if it meant that including the charset made the test fail. Its a perfectly valid value for the content-type; a strong argument could be made that its better. Is it possible to do a starts-with style check, so that both are acceptable?
Richard Ettema (May 04 2017 at 11:46):
@Abigail Watson The FHIR specification does define the required values for the HTTP Content-Type Header here http://hl7.org/fhir/STU3/http.html#mime-type. The following paragraph from this section describes the mandatory use [SHALL] of the "charset" parameter:
FHIR uses UTF-8 for all request and response bodies. Since the HTTP specification (section 3.7.1) defines a default character encoding of ISO-8859-1, requests and responses SHALL explicitly set the character encoding to UTF-8 using the charset parameter of the MIME-type in the Content-Type header. Requests MAY also specify this charset parameter in the Accept header and/or use the Accept-Charset header.
Richard Ettema (May 04 2017 at 12:41):
@Abigail Watson I just finished reading through the links you provided. After reading the discussion on the github thread, I would have to say I agree with the assessement that the charset parameter is not defined for the mime-type of "application/json".
However, we are not talking about "application/json". We are talking about the FHIR specification defined mime-types for FHIR content. And that mime-type for FHIR JSON content is "application/fhir+json" which does have a required parameter of "charset=utf-8" (case-insensitive) within the Content-Type header of the request and response.
Abbie Watson (May 04 2017 at 14:56):
Well, happy to acknowledge that Touchstone is implementing to the FHIR spec. It just seems that the current FHIR spec has either arbitrarily or accidentally determined that Node libraries are not valid FHIR servers. Drat.
How would we go about petitioning that the FHIR spec be changed to something along the lines of "responses SHALL EITHER explicitly set the character encoding to UTF-8 using the charset parameter of the MIME-type in the Content-Type header OR specify this charset parameter in the Accept header and/or use the Accept-Charset header."? Who would we talk to and escalate this issue on the FHIR side?
I'll get started petitioning the request.js folks to allow extended Content-Type settings, citing this use-case. It will take quite some time to move the change through the dependency chain.... request.js, express.js, meteor.js, json-routes, clinical-meteor, etc. I would expect 6 months or more before such a change will get from a GitHub issue to our servers.
In the meantime, could we look at adjusting the tests to use the starts-with check, and do a Warning instead of an Error? Would that take a lot of work?
Richard Ettema (May 04 2017 at 15:05):
Creating a gforge tracker item would the first thing to do.
I'll be in Madrid for the FHIR Connectathon and HL7 WGM and can bring this up for discussion.
Regarding the Touchstone TestScripts, I'll need to review how best to handle this little wrinkle. (And I thought I wouldn't have anything to do on the flight over. 
)
Abbie Watson (May 04 2017 at 15:12):
Okay, I haven't done one of those before. I'll create an account.
Richard Ettema (May 04 2017 at 15:23):
@Abigail Watson Can you confirm that you are using Meteor for your JavaScript development? Are you using an IDE; for example, Webstorm? (just curious)
Abbie Watson (May 04 2017 at 15:33):
Yes, I'm using Meteor. Specifically, I maintain the Clinical Meteor distro, which has healthcare specific packages beyond the core release. Currently, I'm using Visual Studio Code.
Richard Ettema (May 04 2017 at 15:34):
Yep, I just found your 'clinical-meteor' github repo. Nice!
Abbie Watson (May 04 2017 at 15:37):
Thanks, I'm analyzing the dependency chain in more detail, and realized this might be caused by connect.js instead of request.js. But they're sort of competing libraries, like underscore and lodash, and seem to have implemented to the same specs. Nonetheless, still trying to find a workaround.
Richard Ettema (May 04 2017 at 15:39):
I'll definitely be downloading and installing this as I would like to have a local copy to test against.
Please let me know when/if you do find a workaround.
Abbie Watson (May 04 2017 at 15:49):
Thanks. If you do, you'll want to start with the Meteor on FHIR repository. I'm another week or two away from releasing RC 18 - Provider Directory. It will have a tutorial on HL7 V2 to FHIR mapping, and some notes on how to do FHIR testing and set up a peer-to-peer network. And hopefully the blockchain libraries.
Richard Ettema (May 04 2017 at 15:53):
Thanks. That's what I'm looking at right now. I'm guessing I should download the 'fhir-connectathon' branch.
Abbie Watson (May 04 2017 at 16:03):
That's the latest branch, yeah. I haven't created a WildFHIR like client search UI yet; so outbound connections are still hard coded. And Epic doesn't support general open-ended queries on the Location, Practitioner, and Organization resource endpoints. So functionality is still a bit limited and requires Postman or other HTTP utilities.
Abbie Watson (May 15 2017 at 18:28):
I successfully logged a tracking ticket on gForge!
http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13409
Last updated: Apr 12 2022 at 19:14 UTC
