New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HAPI doesn't set an accept header by default #250

Closed
dionmcm opened this Issue Nov 5, 2015 · 3 comments

Comments

Projects
None yet
3 participants
@dionmcm

dionmcm commented Nov 5, 2015

By default, HAPI does't set an accept header by default. Also unless explicitly set, HAPI doesn't set the _format parameter.

As a result requests to a FHIR server by default don't specify an expected/required response format, yet HAPI expects to get application/xml-fhir or application/json-fhir or it will throw a ca.uhn.fhir.rest.client.exceptions.NonFhirResponseException. Some servers (like Ontoserver) will respond with text/html if format is not specified which is useful for naive clients or users pointing a browser at these REST urls.

A client should always specify the format it expects - please change HAPI to always specify the format it is expecting. I've created a ticket against the FHIR specification to add this clarification. http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=8978

@bdenton

This comment has been minimized.

Collaborator

bdenton commented Nov 5, 2015

I would further this comment in saying that the client should also be tolerant of servers that just respond with application/xml, text/xml, or application/json… all without the ‘-fhir’ or ‘+fhir’ part. Not all servers are going to be able to produce those non-conventional content-types especially with things like proxies and gateways in the middle.

From: dionmcm [mailto:notifications@github.com]
Sent: Wednesday, November 04, 2015 10:41 PM
To: jamesagnew/hapi-fhir
Subject: [hapi-fhir] HAPI doesn't set an accept header by default (#250)

By default, HAPI does't set an accept header by default. Also unless explicitly set, HAPI doesn't set the _format parameter.

As a result requests to a FHIR server by default don't specify an expected/required response format, yet HAPI expects to get application/xml-fhir or application/json-fhir or it will throw a ca.uhn.fhir.rest.client.exceptions.NonFhirResponseException. Some servers (like Ontoserver) will respond with text/html if format is not specified which is useful for naive clients or users pointing a browser at these REST urls.

A client should always specify the format it expects - please change HAPI to always specify the format it is expecting. I've created a ticket against the FHIR specification to add this clarification. http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=8978


Reply to this email directly or view it on GitHubhttps://github.com//issues/250.

@jamesagnew

This comment has been minimized.

Owner

jamesagnew commented Nov 5, 2015

Hi @dionmcm , @bdenton ,

This issue is actually already fixed- but only in the 1.3-SNAPSHOT build. Someone else discovered it as a part of Argonauts testing about two weeks ago. You can see this in the request headers on a request on our demo site

And yup, we also accept application/xml and application/json and treat them the same way as the equivalent correct FHIR types. That part has been in more or less from the start. Thinking about this, we don't accept the text equivalents text/xml or text/json. I suppose we probably should just to be complete.

@jamesagnew jamesagnew closed this in 6fd5aec Nov 5, 2015

@dionmcm

This comment has been minimized.

dionmcm commented Nov 18, 2015

Thanks for responding so quickly @jamesagnew, great that it was already spotted and fixed.

@bdenton I agree that clients should probably be lenient and handle application/xml and application/json without the +fhir part.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment