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
