Hi Andriy, thanks for your reply and the suggested solution. I agree that for HTTP 500 interceptors would be a solution. But not for other HTTP error codes (i.e. HTTP 503). The conduit sets the response payload to the CXFMessage, which then can be accessed by the interceptors. For HTTP 503 the Conduit will not read the error payload but will only provide the "Service Not Available" message as payload: https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HTTPConduit.java#L1618
So in this case it would not be possible to access the error payload via interceptor, right? Best regards, Manuel -----Original Message----- From: Andriy Redko <[email protected]> Sent: Donnerstag, 3. Juni 2021 02:43 To: Shenavai, Manuel <[email protected]>; [email protected] Subject: Re: Get error payload for HTTP 503 Hi Manuel, Exposing raw exception details is, in general, considered harmful since there could senstive information leaked outside (fe, to malicious actor). I believe you should be able to plug your custom interceptor [1] and extract the details in question without any modifications to the core. Hope it makes sense. [1] https://cxf.apache.org/docs/interceptors.html Best Regards, Andriy Redko SM> Hi everyone, SM> when using CXF as a client, we get limited error details for HTTP 503. Any response payload provided by the server is not visible. SM> For example: When calling a webservice with CXF results in HTTP 503, the error we see will be: SM> "503 - Service Unavailable" SM> However, the error response from the server contains more details (like: "The configuration is probably not correct. Please check xyz...") SM> From the coding I think the payload is ignored in the case of "IO exceptions". With the following change, I'm able to retrieve the error payload: SM> https://github.com/mash-sap/cxf/commit/b3a4644aada726b4211c2d0531739fdebc202bae SM> I introduced a property to enable the new behavior. Do you know if there is a different way to get the errorpayload? If there is no other way, do you see any problem with this change? Else I would try to create a pullrequest for it. SM> Thanks in advance & SM> Best regards, SM> Manuel
