From: Giacomo P. <gia...@gm...> - 2014-02-04 07:44:02
|
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...@ja...> 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 < > gia...@gm...> 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 >> Hl7...@li... >> https://lists.sourceforge.net/lists/listinfo/hl7api-devel >> >> > |