HTTP Response - HTML in stead of SOAP

[Remcovanderwerf]

Hi,

While testing towards the 'https://lprws-test.sds.dsdn.dk/cda-ws/DocumentRepository_Service/PatientHealthcareSaveIfNoErrorsReportingService' endpoint i have been getting some 'Response code - 500; Service unavailable' replies which could be a normal situation.

The strange thing is that these replies are from the Content-Type: text/html in stead of text/xml which is required/expected for a SOAP 1.2 connection.

My log file says the following (see attachment): response code 500.txt

I got this response on Sat Oct 6 02:03:12 2018 and we are sending from IP: 193.163.235.203 (which is a proxy between our server/software and the endpoint)

I already added a HTTP accept header (text/xml) in the ITI-41 request but unfortunately this did not help.

This issue has some overlap with issue #187 and #175

Could you investigate whether or not LPR3 is responding with a SOAP or HTML layout?

Thank you in advance!

Kind regards,

Remco van der Werf Enovation | The Netherlands Contractor: Region Syddanmark

[jkiddo]

Your log file is dated Date=[Mon, 10 Sep 2018 14:40:47 GMT] - perhaps you attached the wrong response?

[Remcovanderwerf]

Hi,

that is correct. If I am correct on both dates the same thing happened. At first I investigated on the proxy side but it looks like the proxy is just forwarding the message and headers towards the requesting server.

[TueCN]

@Remcovanderwerf you get a response with HTTP status 500 (should really be 503) when the service is offline. Regardless of the Content-Type in the response, the SOAP specification states that the sender (you) must handle the response, as long as the returned HTTP status code is one of the listed status codes on: https://www.w3.org/TR/soap12-part2/#http-reqbindwaitstate

Also see https://scandihealth.github.io/lpr3-docs/interface/xdr/index.html#xdr-interface

Actually, if I read the spec correctly, any response is a valid SOAP response:

If a SOAP message is present, the next state is "Sending+Receiving" or "Receiving", otherwise the next state is "Fail"

Since a SOAP message is not present in the response, you can go to the "Fail" state.

[wilgerh]

Hi @TueCN : Actually, I think this is a misinterpretation of the SOAP standard. You're referring to properties that belong to the 'requesting SOAP node' but you should have a look at paragraph 7.5.2 'Behavior of Responding SOAP Node'. Since your server is the responding SOAP Node and sending a response, you're in the 'Receiving' state at your node and you should response with a SOAP fault. Moreover, you are also making use of the IHE XDR profile, that makes use of ebXML. Both ebXML and XDR are providing extra details of how a SOAP response message should be formatted and sent back and sending back an HTTP 500 response containing HTML is not conform these standards (SOAP 1.2, ebXML, IHE XDR).

However, I can imagine that, when your service in completely off-line, it's sending back a HTTP 503 response. From your answer I get that it should be that error type: do you mean that LPR3 is sending back the wrong HTTP status now when the service is off-line and that's a bug that is going to be fixed? We would be happy with that in the first place and, at second hand, it would be nice if other error states are responded in the right way, following the rules of the applying standards.

Thanks for your reaction in advance.

Kind regards, Wilger Hooijmeijer Enovation | The Netherlands Contractor: Region Syddanmark

[jonigkeit]

Hi @wilgerh

Returning status code 500 is conform with SOAP 1.2. Actually returning any HTTP status code is conform and the behavior of a conforming requesting SOAP node is described as well.

The SOAP HTTP binding follows the rules of any HTTP application which means that an implementation of the SOAP HTTP binding must understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response must not be cached.

What the requesting SOAP node uses the content of a HTTP response with status code 500 is not described and you can do whatever you want with it.

[TueCN]

Hi @wilgerh yes I am looking at how the 'requesting node' should handle a SOAP request/response. What actually happens on the server does not seem relevant in this discussion.

7.5.1 Behavior of Requesting SOAP Node 7.5.1.2 Requesting In the "Requesting" state, sending of the request continues while waiting for the start of the response message. Table 17 details the transitions that take place when a requesting SOAP node receives an HTTP status line and response header fields. For some status codes there is a choice of possible next state. In cases where "Fail" is one of the choices, the transition is dependent on whether a SOAP message is present in the HTTP response. If a SOAP message is present, the next state is "Sending+Receiving" or "Receiving", otherwise the next state is "Fail"

Above paragraph suggests that a SOAP message is not required to be present for the message exchange to be considered a SOAP Request-Response Message Exchange.

This seems to be backed by the SOAP Request-Response Message Exchange Pattern - Description:

The response message MAY contain a SOAP envelope, or else the response MUST be a binding-specific message indicating that the request has been received.

To me this indicates that the HTTP status code alone is sufficient to process the response, as the HTTP status code in the response is a binding-specific message that indicate the request has been received.

[wilgerh]

Hi @TueCN , @jonigkeit,

Thanks for your reply. You're pasting a small part of the SOAP standard to support your stand, while leaving out other relevant information. I don't want to be rude, but it is simply wrong to send a HTTP 500 response without a SOAP envelop. Please read carefully '7.5.2 Behavior of Responding SOAP Node' (https://www.w3.org/TR/soap12-part2/#http-bindrespnode)

This paragraph explains that there are different states, starting with the 'init' state: this is the only state where I could imagine sending back a non-SOAP response, because the server (responding SOAP Node) is completely unable to process the message, because for example the message is malformed. I can imagine that a 503 would also be part of the list of status codes that could sent back in this state, because that would indicate that your service is unavailable, but it is not on the list in the SOAP standard. After the init state, you are in the 'receiving' state: since the LPR3 service is not sending back a HTTP status code defined in the init state, we are automatically talking about this receiving state and the standard clearly states which SOAP faults you should response with if something goes wrong in this state. Actually, more rules are applying on the response messages you sent back during this state, because LPR3 is making use of ebXML and XDR, so for example in ITI TF volume 3 you can find back specific rules that should be applied to SOAP responses.

So, main point is: a HTTP 500 with other content then SOAP isn't allowed and therefore we can't support, underlying developing frameworks are not allowing us. It would be an option for us (like @TueCN stated also in his comment of October 9) if LPR3 sends back a HTTP 503 error with HTML-content instead of a HTTP 500 error.

[wilgerh]

Hi @TueCN , @jonigkeit,

Can you please respond and give at least clarity if it's possible for you to return a HTTP 503 error in case your service isn't available? This information is crucial to us to decide if we need to follow the route to implement a workaround at our side. Thanks in advance.

[TueCN]

Hi @wilgerh sorry I do not know yet. I need to get it clarified through key resources. I will try to escalate the issue.

[TueCN]

RESOLUTION The LPR service will now set HTTP status 503 on a response when the service is unavailable. The content of the response will still contain HTML (which as per @wilgerh comment https://github.com/scandihealth/lpr3-docs/issues/201#issuecomment-431346085 is acceptable for their needs)

The change is still untested and will be tested by DXC during next service window (Tuesday)

[TueCN]

Tested OK during latest service window

[TueCN]

@wilgerh @Remcovanderwerf I am closing the issue as it has been resolved for 1 month.

Feel free to reopen the issue if you have further remarks.