· Feb 9

Content Type change in IIS?


I have a problem with a FHIR Interop scenario that the HTTP Header Value content-type between IRIS and client changes in case of an error (HTTP 422). If I set the status in the response to 200 OK as the last step in the service class, the return transmission works.

Within my operation class, the error code is taken from the source system and entered in the HS.FHIRServer.Interop.Response message. 

Within the CSP gateway I am also shown that the content type is 422 application/fhir+xml and is returned.

When I look at the packet in Wireshark, it is already text/html. 
A URL rewrite is not active here.

On the target system (test Thunder Client / Postman) the content type text/html is displayed for HTTP 422.

Based on the process flow, the error should be in the IIS. Unfortunately, I have no idea where to look for the corresponding setting. 

So my question, has anyone ever had this problem and could give me a tip?


With kind regards


Product version: IRIS 2023.1
$ZV: IRIS for Windows (x86-64) 2023.1.1 (Build 380U) Fri Jul 7 2023 23:43:12 EDT
Discussion (3)3
Log in or sign up to continue

My guess (I may be wrong!) is that you did not configure IIS existingResponse PassThrough option.

In IIS, if you don't configure that options, application errors (like IRIS REST errors) are not sent back to the client, instead a "standard IIS error" (my definition) is sent back to the client (i.e. browser).

Check this IRIS documentation on Configuring IIS to Return SOAP Fault Details, although it refers to soap, the same apply to REST.
You may want to google "IIS existingResponse PassThrough" for more info.

Again, I may be wrong...but I bet on this being the issue here.