#243 Bug in the HoH implementation/spec

[Jens Villadsen]

There seems to be a bug in the Hoh implementation and the spec for the "HL7 over HAPI". The spec states initially (on http://hl7api.sourceforge.net/hapi-hl7overhttp/specification.html#a2.4_Content_Type_and_Character_Set) that the content type should be one of the following:

If the message is a "vertical bar" encoded HL7 v2.x message, the content type SHALL be:
x-application/hl7-v2+er7
If the message is an XML encoded HL7 v2.x message, the content type SHALL be:
x-application/hl7-v2+xml
If the message is an XML encoded HL7 v3 message, the content type SHALL be:
x-application/hl7-v3+xml
If the message is an XML encoded FHIR message, the content type SHALL be:
x-application/fhir+xml
If the message is a JSON encoded FHIR message, the content type SHALL be:
x-application/fhir+json
If the message is a CDA document, the content type SHALL be:
x-application/xml+cda
If the response message content is not an HL7 message (for instance because the server is malfunctioning and returning a 500 status or the URI being addressed is unknown and the server is returning a 404 status), the content SHALL be another type, such as
text/html or text/plain

Later on, an example is showed:

"
An example follows which shows the Content-Type header used to indicate that a "vertical bar" encoded message is being transmitted.

Content-Type: application/hl7-v2+er7; charset=utf-8
"

Now, the content type should have included the "x-" as spec'ed previously.

But it becomes worse:

The Hoh implementation actually neither expects application/hl7-v2+er7 or x-application/hl7-v2+er7 - it expects application/hl7-v2 (see for yourself at ca.uhn.hl7v2.hoh.encoder.EncodingStyle).