Thanks for the exhaustive answer, as always. It's nice to hear that these
issues have already been addressed.
Good job!
On Mon, Feb 3, 2014 at 11:10 PM, James Agnew <ja...@jamesagnew.ca> wrote:
> Hi Giacomo,
>
> Unfortunately this is a case of the code being behind the specification.
> At the previous HL7 working group meeting the ITS (implementable technology
> specification) group approved two changes to the spec:
> * HTTP 200 response code for all valid HL7 message responses (the
> rationale being that AE/AR/etc are application level problems and not
> transport level problems)
> * UTF-8 character set is mandatory for sending applications (rationale
> being that character encodings have been a huge source of issues over the
> years, and support for UTF-8 is basically universal these days so it makes
> sense to do away with schemes that can't support all characters)
>
> These two changes have been implemented but not yet released. The final
> HAPI 2.2 release will fix this. I'm hoping we'll have this released very
> shortly, the one showstopper bug in 2.2 (bug 206: a glitch in MLLP over
> slow networks) was fixed last week so we should be good to go.
>
> Cheers,
> James
>
>
>
>
> On Tue, Jan 28, 2014 at 3:31 PM, Giacomo Petronio <
> giacomo.petro...@gmail.com> wrote:
>
>> Hi, I think that there is a mismatch between the HL7 Over HTTP
>> specification and the current implementation regarding the HTTP Response
>> Codes.
>> The specification says:
>>
>> When a *receiving application* produces an HL7 response payload
>>> containing one of these status codes (AR, AE, CR, CE), this is considered a
>>> successful interaction at the transport layer, and response code of
>>> "HTTP/1.1 200 OK" MUST be used.
>>
>>
>> But the implementation does not follow the specification. The class
>> ca.uhn.hl7v2.hoh.encoder.ResponseCode
>> contains the following mapping:
>>
>> ourAckCodesToResponseCodes.put(AA, HTTP_200_OK);
>> ourAckCodesToResponseCodes.put(CA, HTTP_200_OK);
>> ourAckCodesToResponseCodes.put(AR, HTTP_400_BAD_REQUEST);
>> ourAckCodesToResponseCodes.put(CR, HTTP_400_BAD_REQUEST);
>> ourAckCodesToResponseCodes.put(AE, HTTP_500_INTERNAL_SERVER_ERROR);
>> ourAckCodesToResponseCodes.put(CE, HTTP_500_INTERNAL_SERVER_ERROR);
>>
>> Is there any reason for this particular behaviour or is this a "bug"?
>> Is it possible to programmatically override these values?
>>
>>
>> ------------------------------------------------------------------------------
>> WatchGuard Dimension instantly turns raw network data into actionable
>> security intelligence. It gives you real-time visual feedback on key
>> security issues and trends. Skip the complicated setup - simply import
>> a virtual appliance and go from zero to informed in seconds.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Hl7api-devel mailing list
>> Hl7api-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>>
>>
>
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Hl7api-devel mailing list
Hl7api-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
