When the SOAP request is too long we are getting '401: Unauthorized'
as a response using JAX-WS in WildFly 11 (Apache CXF under the hood).
We are calling a SOAP Web Service from WildFly to SharePoint, using NTLM protocol.
If the request size is short it works fine, but if the request is "large" (SOAP messages with 1MB for example) it fails with error HTTP 401. We are using this web service to send images, but encoded as base64 binary.
We tried to call the service using SOAP UI and it worked, so it seems a problem in the application server. What could be happening, and, what workarounds could we use?
Update: Jira issue CXF-5890 seems to be somewhat similar to this.
Our client code is very simple, we send a BASE64 byte array (s:base64Binary):
@Stateless
public class Client {
@WebServiceRef(wsdlLocation = "/wsdl/service.wsdl")
private ServiceRepository service;
public void send() {
Repository repository = service.getRepositorySoap();
Map<String, Object> requestContext = ((BindingProvider) repository).getRequestContext();
requestContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "http://customerendpoint/service.asmx");
// sets standard Java authentication for NTLM
authtWsSharepoint();
// This method loads an image in BASE64. We found the problem around 45,000 characters, but it is not exact
String image = getImage();
repository.submitFile(image.getBytes());
}
}
We are using standard Java authenticator:
private void authtWsSharepoint() throws Exception {
Authenticator sAuthService = new Authenticator() {
@Override
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication("domain\\user", "password".toCharArray());
}
};
Authenticator.setDefault(sAuthService);
}
Here is the exception:
Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '401: Unauthorized' when communicating with http://customerendpoint/service.asmx
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1581)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1533)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1336)
at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:652)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:516)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138)
... 110 more
The magic happens here
httpClientPolicy.setAllowChunking(false)
. Setting this to false solved the problem.Code example
Dependencies
jboss-deployment-structure.xml