Content Type change in IIS?
Hello,
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.
.png)
Within the CSP gateway I am also shown that the content type is 422 application/fhir+xml and is returned.
.png)
When I look at the packet in Wireshark, it is already text/html.
A URL rewrite is not active here.
.png)
On the target system (test Thunder Client / Postman) the content type text/html is displayed for HTTP 422.
.png)
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
Armin
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.
Thank you very much, that was the right hint.
As it is a Rest Service that does not contain a CSP in the path, I had to edit the default path directly. But that is not a problem in my scenario.
Kind regards
Armin
It seems like a problem with the web.config file:
https://stackoverflow.com/questions/53106327/web-config-error-handler-fo...