Hi Andriy, thanks for the suggestion. I will give it a try!
Best regards, Manuel -----Original Message----- From: Andriy Redko <[email protected]> Sent: Mittwoch, 9. Juni 2021 01:50 To: Shenavai, Manuel <[email protected]>; [email protected] Subject: Re: Get error payload for HTTP 503 Hi Manuel, Indeed for 4xx and 5xx CXF has a special treatment, in this case you already have the mechanisms to adapt the behavior to your needs. If you set "org.apache.cxf.transport.no_io_exceptions" (HTTPConduit.NO_IO_EXCEPTIONS) to "true", it will let you handle all erroneous messages by yourself, including payload retrieval, w/o interceptor, for example: client.getRequestContext().put(HTTPConduit.NO_IO_EXCEPTIONS, true); client.getInFaultInterceptors().add(new PhaseInterceptor<Message>() { @Override public void handleMessage(Message message) throws Fault { ... } ... } In handleMessage(), you have a choice to throw HTTPException with the message you needed in first place, just a sample snippet below: @Override public void handleMessage(Message message) throws Fault { final int status = (int)message.get(Message.RESPONSE_CODE); final URL url = new URL(message.get(Conduit.class).getTarget().getAddress().getValue()); final SoapFault soapFault = (SoapFault)message.getContent(Exception.class); throw new Fault(new HTTPException(status, soapFault.getMessage(), url)); } It is certainly a bit of coding but gives you the flexibility to tailor HTTP conduit up to your use case. There are a number of other options available. Hope it helps, thank you! Best Regards, Andriy Redko SM> Hi Andriy, SM> 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: SM> https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HTTPConduit.java#L1618 SM> So in this case it would not be possible to access the error payload via interceptor, right? SM> Best regards, SM> Manuel SM> -----Original Message----- SM> From: Andriy Redko <[email protected]> SM> Sent: Donnerstag, 3. Juni 2021 02:43 SM> To: Shenavai, Manuel <[email protected]>; [email protected] SM> Subject: Re: Get error payload for HTTP 503 SM> Hi Manuel, SM> Exposing raw exception details is, in general, considered harmful since there could SM> senstive information leaked outside (fe, to malicious actor). I believe you should be able SM> to plug your custom interceptor [1] and extract the details in question without any SM> modifications to the core. Hope it makes sense. SM> [1] https://cxf.apache.org/docs/interceptors.html SM> Best Regards, SM> 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
