We Keep Coding

HttpClient on .NET 7 fails on Kerberos authentication

We've upgraded our application from .NET 6 to .NET 7 and now the Kerberos authentication fails. I've created a simple console application to replicate the behavior and built it for both .NET 6 and .NET 7. The .NET 6 application does a successful authentication, but .NET 7 fails with the stacktrace below.
OS: Windows Server 2019 Standard
.NET Version: 7
Application: WPF and
Console App, same behavior.
using System.Configuration;
Console.WriteLine("Beep boop bop... starting application");
HttpClientHandler handler = new()
{
UseDefaultCredentials = true,
PreAuthenticate = true,
};
handler.ServerCertificateCustomValidationCallback = (httpRequestMessage, cert, cetChain, policyErrors) => {
return true;
};
HttpClient client = new(handler);
string url = ConfigurationManager.AppSettings["IdpUrl"];
Console.WriteLine($"Requesting: {url}");
HttpResponseMessage? response = await client.GetAsync(url);
Console.WriteLine($"Response status code: {response.StatusCode}");
Console.WriteLine($"Response: {response}");
Console.WriteLine("Beep boop bop... signing off");
Console.ReadLine();
The stacktrace:
System.Net.Http.HttpRequestException: Authentication validation failed with error - InvalidToken. at System.Net.Http.AuthenticationHelper.SendWithNtAuthAsync(HttpRequestMessage request, Uri authUri, Boolean async, ICredentials credentials, Boolean isProxyAuth, HttpConnection connection, HttpConnectionPool connectionPool, CancellationToken cancellationToken) at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken) at System.Net.Http.AuthenticationHelper.SendWithAuthAsync(HttpRequestMessage request, Uri authUri, Boolean async, ICredentials credentials, Boolean preAuthenticate, Boolean isProxyAuth, Boolean doRequestAuth, HttpConnectionPool pool, CancellationToken cancellationToken) at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken) at System.Net.Http.HttpClient.g__Core|83_0(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationTokenSource cts, Boolean disposeCts, CancellationTokenSource pendingRequestsCts, CancellationToken originalCancellationToken)
From a Kerberos point of view, this is the normal process:
Call happens to a URL
The server replies with met een 401 and WWW-Authenticate: Negotiate header
Client replies with a kerberos token
The server does the Kerberos validation and returns a 200 reply with in the body a valid JWT which is the case.
I've omitted the token(s) for privacy reasons and added some X's where other data use to be.
Fiddler results for the Kerberos authentication:
HTTP/1.1 401
Server: xxxxxxxx
Date: Mon, 06 Feb 2023 10:13:22 GMT
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 519
Connection: keep-alive
Set-Cookie: XX_JSESSIONID=XXXXXXXXXXXXXXXXXXXXXXXXXXXX; Path=/xx; Secure; HttpOnly; SameSite=None
Cache-Control: no-store
WWW-Authenticate: Negotiate
Pragma: no-cache
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000; includeSubdomains;
Cache-Control: private, max-age=0, no-cache, no-store
Pragma: no-cache
Proxy-Support: Session-Based-Authentication
HTTP/1.1 200
Server: xxxxxx
Date: Mon, 06 Feb 2023 10:13:22 GMT
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 1124
Connection: keep-alive
Set-Cookie: XX_JSESSIONID=XXXXXXXXXXXXXXXXXX; Path=/xx; Secure; HttpOnly; SameSite=None
WWW-Authenticate: Negotiate (A TOKEN)
Cache-Control: max-age=0
Pragma: no-cache
Expires: Mon, 06 Feb 2023 10:13:22 GMT
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000; includeSubdomains;
Cache-Control: private, max-age=0, no-cache, no-store
Pragma: no-cache
I was expecting the same behavior in .NET and a successful Kerberos authentication.

Azure storage REST group transactions - one of the request inputs is out of range

I'm trying my hand at entity group transactions with a very simple request, but keep getting a "400 (one of the request inputs is out of range)" error code in the response. Here's the string-serialized HttpRequestMessage:
Method: POST, RequestUri: 'http://127.0.0.1:10002/$batch?', Version: 1.1, Content: System.Net.Http.StringContent, Headers:
{
x-ms-date: Tue, 21 Oct 2014 18:49:09 GMT
x-ms-version: 2014-02-14
Authorization: SharedKeyLite devstoreaccount1:vdQ+5/Kmw43u+DcqpWCX14n24WG8hsubtTK5pnK1xO8=
Content-Type: multipart/mixed; boundary=batch_f351702c-c8c8-48c6-af2c-91b809c651ce
Content-Length: 212
}
And the string-serialized request content:
--batch_f351702c-c8c8-48c6-af2c-91b809c651ce
Content-Type: application/http
Content-Transfer-Encoding: binary
GET http://127.0.0.1:10002/batchTable() HTTP/1.1
--batch_f351702c-c8c8-48c6-af2c-91b809c651ce--
The response from the server:
StatusCode: 400, ReasonPhrase: 'One of the request inputs is out of range.', Version: 1.1, Content: System.Net.Http.StreamContent, Headers:
{
x-ms-request-id: 43fea847-2226-4dcf-ad62-bdb7cc0af256
Date: Wed, 22 Oct 2014 00:00:06 GMT
Server: Microsoft-HTTPAPI/2.0
Content-Length: 325
Content-Type: application/xml
}
response content:
<?xml version="1.0" encoding="utf-8"?><m:error xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"><m:code>OutOfRangeInput</m:code><m:message xml:lang="en-US">One of the request inputs is out of range.
RequestId:43fea847-2226-4dcf-ad62-bdb7cc0af256
Time:2014-10-22T00:00:06.3046099Z</m:message></m:error>
Any idea what the problem could be?
Thanks!
Edit: Messing up the authorization header doesn't cause a 403 error, in case that helps.
Edit 2: I also get no error if I try batching a single insert - but the insert also doesn't take place:
Method: POST, RequestUri: 'http://127.0.0.1:10002/devstoreaccount1/$batch?', Version: 1.1, Content: System.Net.Http.StringContent, Headers:
{
Accept: application/atom+xml
x-ms-date: Wed, 22 Oct 2014 16:38:34 GMT
x-ms-version: 2014-02-14
DataServiceVersion: 1.0
MaxDataServiceVersion: 3.0
Authorization: SharedKeyLite devstoreaccount1:Eb4JHmCsuL6aLMTGEWs+gt23zbKjAdYjO12YmeYHjf0=
Content-Type: multipart/mixed; boundary=batch_boundary
Content-Length: 1008
}
Content.ToString():
--batch_boundary
Content-Type: multipart/mixed; boundary="changeset_boundary"
Content-Length: 885
--changeset_boundary
Content-Type: application/http
Content-Transfer-Encoding: binary
POST http://127.0.0.1:10002/devstoreaccount1/batchTable? HTTP/1.1
Content-ID: 1
Content-Type: application/atom+xml;type=entry
Content-Length: 559
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<entry xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns="http://www.w3.org/2005/Atom">
<title />
<updated>2014-10-22T16:38:34.6393109Z</updated>
<author>
<name />
</author>
<id />
<content type="application/xml">
<m:properties>
<d:PartitionKey m:type="Edm.String">foo</d:PartitionKey>
<d:RowKey m:type="Edm.String">foo</d:RowKey>
<d:IntVal m:type="Edm.Int32">1</d:IntVal>
</m:properties>
</content>
</entry>
--changeset_boundary--
--batch_boundary--

The issue was that the URI was http://127.0.0.1:10002/$batch instead of http://127.0.0.1:10002/devstoreaccount1/$batch. sigh

It looks like you are using an older version of Azure Storage Emulator, which does not support 2014-02-14 version. Could you please make sure your Emulator version is at least 3.2? If it is not, please upgrade to the latest version.

ProtocolException: The incoming transaction cannot be deserialized

I have a simple WCF Service running on different environments. Today I tried to run it on my Windows 7 workstation and got this error on my client (which is simple console application for testing):
System.ServiceModel.ProtocolException: The incoming transaction cannot be deserialized. The transaction header in the message was either malformed or in an unrecognized format. The client and the service must be configured to use the same protocol and protocol version. The following exception occurred: Communication with the underlying transaction manager has failed.
Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter)
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at ConsoleApplication1.ServiceReference1.ILookupService.GetMaritalStatus()
at ConsoleApplication1.ServiceReference1.LookupServiceClient.GetMaritalStatus() in D:\\Temp\\ConsoleApplication1\\ConsoleApplication1\\Service References\\ServiceReference1\\Reference.cs:line 46975
at ConsoleApplication1.Program.Main(String[] args) in D:\\Temp\\ConsoleApplication1\\ConsoleApplication1\\Program.cs:line 24
If I change endpoint on the client to call the same service from any other environment - it works just fine. I'm sure that something wrong with my workstation, but cannot figure out what is that. All settings in IIS are the same as on other servers. Other services work fine on the workstation.
The service contract looks like:
[ServiceContract]
public interface IMyService
{
[OperationContract]
[TransactionFlow(TransactionFlowOption.Allowed)]
[FaultContract(typeof(ServiceFault))]
Result MethodName(Guid id);
}
Implementation:
[ServiceBehavior(Name = "MyService", InstanceContextMode = InstanceContextMode.PerCall)]
public class MyService : IMyService
{
public Result MethodName(Guid id)
{
...
}
}
I haven't created this service, and not sure why we may need TransactionFlow attribute. Is that causes the issue. How can I fix it?
Fiddler showed the following response. Nothing that could help.
HTTP/1.1 500 Internal Server Error
Content-Length: 905
Content-Type: application/soap+xml; charset=utf-8
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Wed, 08 Jan 2014 18:45:33 GMT
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/transactions/fault</a:Action></s:Header><s:Body><s:Fault><s:Code><s:Value>s:Sender</s:Value><s:Subcode><s:Value xmlns:a="http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/transactions">a:TransactionHeaderMalformed</s:Value></s:Subcode></s:Code><s:Reason><s:Text xml:lang="en-US">The incoming transaction cannot be deserialized. The transaction header in the message was either malformed or in an unrecognized format. The client and the service must be configured to use the same protocol and protocol version. The following exception occurred: Communication with the underlying transaction manager has failed.</s:Text></s:Reason></s:Fault></s:Body></s:Envelope>

Looks like MSDTC security settings were reset by Windows Updates. I found the following log entries in the Windows Logs:
MSDTC encountered an error (HR=0x80000171) while attempting to establish a secure connection with system <HostName>.
So I did two things:
1) Granted with Full Access the NetworkServices for msdtc.log:
icacls c:\windows\system32\msdtc\msdtc.log /grant "networkservice":F
2) Changed security settings for the Local DTC (Control Panel -> Administrative Tools -> Component Services -> My Computer -> Distributed Transaction Coordinator -> Local DTC -> Properties). I set the following (nothing was set at all):

Web Service XML response being received as "text/plain". (Yet another content type error.)

I am attempting to develop a web application that submits a simple login request to a web service using WCF, but I keep getting "content type text/plain of the response message does not match" errors, even though the web service appears to be returning valid XML.
I've reviewed the dozens of similar S.O. posts regarding this error and have ruled out the more common possibilities:
I can see in the response that it's not an Error page coming back (as discussed here).
I don't appear to have a binding mismatch issue (as discussed here). My app and
the web service are both using SOAP 1.1 and I have "basicHttpBinding" specified.
The response included in my error message appears to show valid XML
that includes the user and response variables that I want.
I can see in the Web Service log files that the login method is
fully executing without throwing an exception.
I pasted the XML response into the W3Schools validator with no
error.
What else could be causing my error, and why isn't this being recognized as valid XML?
I am using .Net 4.0 and Visual Studio 2010 for my application, which is communicating with a Java/Tomcat web service on a separate server.
Here are the relevant excerpts from my login code:
AuthenticationServiceClient client = new AuthenticationServiceClient(strPortName, strURL);
client.Open();
UserCredentials credentials = new UserCredentials();
credentials.userName = TestUsername;
credentials.password = TestPassword;
LoginResponse response = client.login(credentials); // Using WCF.
Here is what the binding looks like in my Web.Config:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="AuthenticationServiceSoapBinding" />
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://mywebserviceurl"
binding="basicHttpBinding" bindingConfiguration="AuthenticationServiceSoapBinding"
contract="MyNamespace.AuthenticationService" name="AuthenticationServiceImplPort" />
</client>
</system.serviceModel>
Here is my Error Message:
Error testing connection to web service at "WebServiceURL": System.ServiceModel.ProtocolException: The content type text/plain of the response message does not match the content type of the binding (text/xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. The first 788 bytes of the response were: '
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<loginReponse xmlns="urn:xxxx">
<authKey>xxxx</authKey>
<authMetadata>
<IPaddress>https://MyWebApplicationURL</IPaddress>
<loginTimestamp>xxxx</loginTimestamp><levelOfAssurance>
<AuthMechanism>xxxx</AuthMechanism>
<VettingAssertion>xxxx</VettingAssertion>
</levelOfAssurance>
</authMetadata>
<errorText></errorText>
<successfulLoginFlag>true</successfulLoginFlag>
<userSummary>
<GUID>xxxx</GUID>
<commonName>xxxx</commonName>
<loginName>xxxx</loginName>
</userSummary>
<passwordExpiryDays>xxxx</passwordExpiryDays></loginReponse>
</soap:Body>
</soap:Envelope>
'.
Server stack trace: at
System.ServiceModel.Channels.HttpChannelUtilities.ValidateRequestReplyResponse(HttpWebRequest
request, HttpWebResponse response, HttpChannelFactory factory,
WebException responseException, ChannelBinding channelBinding) at
System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan
timeout) at
System.ServiceModel.Channels.RequestChannel.Request(Message message,
TimeSpan timeout) at
System.ServiceModel.Channels.ServiceChannel.Call(String action,
Boolean oneway, ProxyOperationRuntime operation, Object[] ins,
Object[] outs, TimeSpan timeout) at
System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage
methodCall, ProxyOperationRuntime operation) at
System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage
message)
Exception rethrown at [0]: at
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessage retMsg) at
System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 type) at
MyNamespace.AuthenticationService.AuthenticationService.login(loginRequest
request) at
MyNamespace.AuthenticationService.AuthenticationServiceClient.MyNamespace.AuthenticationService.AuthenticationService.login(loginRequest
request) in C:...\AuthenticationService\Reference.cs:line 1716 at
MyNamespace.AuthenticationService.AuthenticationServiceClient.login(UserCredentials
credentials) in C:...\AuthenticationService\Reference.cs:line 1722
at MyNamespace.Forms.TestWebService.TestLogin_Click(Object sender,
EventArgs e) in C:...\TestWebService.aspx.cs:line 284
Here is what my response from the Web Service looks like in WireShark:

The problem is that the service is responding with text/plain when it should be responding with text/xml or application/xml which is what your WCF binding expects in order to properly handle it. Fundamentally this is an "issue" on the service side: they are returning XML but calling it plaintext, which technically is accurate but not as specific as an XML content type. On the WCF side, the built-in protocol handling is fairly rigid and expects the content type to be text/xml or application/xml in order to proceed with deserializing it.
You could thwart their content type problem by writing a custom WCF encoder that supports text/plain but parses it as XML.

this issue can occur if WCF Activation Components have not been installed. Please check below link for more information and similar issue faced
http://bit.ly/1fYZ2wn

WCF unable to parse Java soap response

I have this response from a Java web service:
HTTP/1.1 200 OK
Date: Mon, 23 Apr 2012 12:08:50 GMT
Server: Jetty/5.1.14 (Linux/2.6.18-274.17.1.el5xen x86 java/1.6.0
Content-Type: text/xml; charset=utf-8
Content-Length: 571
--MIMEBoundaryurn_uuid_14B7343BF98675BB5D1335182931028
Content-Type: application/xop+xml; charset=utf-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:14B7343BF98675BB5D1335182931029#apache.org>
<?xml version="1.0" encoding="utf-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><ns1:loginResponse xmlns:ns1="http://www.telelogic.com/change/types"><token>206398089429929753</token></ns1:loginResponse></soapenv:Body></soapenv:Envelope>
--MIMEBoundaryurn_uuid_14B7343BF98675BB5D1335182931028--
The exception from WCF is telling me The data at the root level is invalid. Line 1, position 1.
My app.config is as following:
<customBinding>
<binding>
<!--<messageModifier />-->
<!--<mtomMessageEncoding messageVersion="Soap11" writeEncoding="utf-8" />-->
<textMessageEncoding writeEncoding="utf-8" messageVersion="Soap11" />
<httpsTransport
requireClientCertificate="false"
transferMode="Buffered" />
</binding>
</customBinding>
As you can see I already tried different settings like mtom/text encodig, soap11/soap12 for message version, buffered and responseStreamed for transferMode. I'm kind of stuck. When I strip some of the response with Fiddler I got it working:
HTTP/1.1 200 OK
Date: Mon, 23 Apr 2012 14:21:44 GMT
Server: Jetty/5.1.14 (Linux/2.6.18-274.17.1.el5xen x86 java/1.6.0
Content-Type: text/xml; charset=utf-8
Content-Length: 571
<?xml version="1.0" encoding="utf-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><ns1:loginResponse xmlns:ns1="http://www.telelogic.com/change/types"><token>206398089429929753</token></ns1:loginResponse></soapenv:Body></soapenv:Envelope>
Am I missing something? Is there a magic combination of config settings I need?
I also tried bot the IClientMessageFormatter and the IClientMessageInspector but they both seem to be too high in the stack because WCF already fails with the ProtocolException telling The data at the root level is invalid. Line 1, position 1..
I hooked in the ChannelMessageInterceptor from the WCF sample. I thought I got that working but now I'm getting exceptions from the java service:
HTTP/1.1 500 Internal Server Error
Date: Mon, 23 Apr 2012 14:40:05 GMT
Server: Jetty/5.1.14 (Linux/2.6.18-274.17.1.el5xen x86 java/1.6.0
Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_14B7343BF98675BB5D1335192006387; type="application/xop+xml"; start="<0.urn:uuid:14B7343BF98675BB5D1335192006388#apache.org>"; start-info="application/soap+xml"; action="http://www.telelogic.com/change/ChangeService/login/Fault/LoginFault";charset=UTF-8
Content-Length: 2853
--MIMEBoundaryurn_uuid_14B7343BF98675BB5D1335192006387
Content-Type: application/xop+xml; charset=utf-8; type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:14B7343BF98675BB5D1335192006388#apache.org>
<?xml version="1.0" encoding="utf-8"?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Body><soapenv:Fault xmlns:axis2ns15="http://www.w3.org/2003/05/soap-envelope"><soapenv:Code><soapenv:Value>axis2ns15:MustUnderstand</soapenv:Value></soapenv:Code><soapenv:Reason><soapenv:Text xml:lang="en-US">Must Understand check failed for header http://www.w3.org/2005/08/addressing : Action</soapenv:Text></soapenv:Reason><soapenv:Detail><Exception>org.apache.axis2.AxisFault: Must Understand check failed for header http://www.w3.org/2005/08/addressing : Action
at org.apache.axis2.engine.AxisEngine.checkMustUnderstand(AxisEngine.java:88)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:137)
at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:121)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
at compressionFilters.CompressionFilter.doFilter(CompressionFilter.java:192)
at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
at com.telelogic.cs.filters.StrutsCharsetFilter.doFilter(StrutsCharsetFilter.java:44)
at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
at org.mortbay.http.HttpServer.service(HttpServer.java:909)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:820)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:986)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:837)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:245)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
</Exception></soapenv:Detail></soapenv:Fault></soapenv:Body></soapenv:Envelope>
--MIMEBoundaryurn_uuid_14B7343BF98675BB5D1335192006387--
At least it is telling me they're using Axis? I've also seen exception messages telling me the content type of the response doesn't match the type from the binding, but I cannot reproduce them at this time.
It looks a lot like this question. I also tried the WCF Soap With Attachments Encoder but it also keeps nagging the Data at the root level is invalid. Line 1, position 1. (but now directly inside a XmlException rather than a ProtocolException).
Update
I have the WCF SWA working!
An example message including an attachment:
HTTP/1.1 200 OK
Date: Tue, 24 Apr 2012 11:27:40 GMT
Server: Jetty/5.1.14 (Linux/2.6.18-274.17.1.el5xen x86 java/1.6.0
Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_14B7343BF98675BB5D1335266861287; type="application/xop+xml"; start="<0.urn:uuid:14B7343BF98675BB5D1335266861289#apache.org>"; start-info="text/xml";charset=UTF-8
Content-Length: 81847
--MIMEBoundaryurn_uuid_14B7343BF98675BB5D1335266861287
Content-Type: application/xop+xml; charset=utf-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:14B7343BF98675BB5D1335266861289#apache.org>
<?xml version="1.0" encoding="utf-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><ns1:downloadAttachmentResponse xmlns:ns1="http://www.telelogic.com/change/types"><attachmentContents><xop:Include href="cid:1.urn:uuid:14B7343BF98675BB5D1335266861290#apache.org" xmlns:xop="http://www.w3.org/2004/08/xop/include"></xop:Include></attachmentContents></ns1:downloadAttachmentResponse></soapenv:Body></soapenv:Envelope>
--MIMEBoundaryurn_uuid_14B7343BF98675BB5D1335266861287
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-ID: <1.urn:uuid:14B7343BF98675BB5D1335266861290#apache.org>
��ࡱ�����������������>���� ����������������������������������������������������������������������������������������������������������������������������������������������
--MIMEBoundaryurn_uuid_14B7343BF98675BB5D1335266861287--
At the moment I'm thinking about invoking the service with a HttpWebRequest because the parsing is much less error prone.
When using the default MTOM Encoder for this specific message it works :S Now I need to dynamically switch encoders?!
I finally got it working. Based on the WCF SWA sample I created a binding extension which uses the TextMessageEncodingBindingElement as default and for sending messages and a fallback mechanism using the MtomMessageEncodingBindingElement when receiving multipart/related messages.
Thank you all.

This soap is formatted like a mime message but in practice there are not attachments. If you have a sample that does contain attachment please publish. Otehrwise I assume tehre are never attachments and I would advise you build your own message encoder that simply strips everything except the soap envelope.

Make sure that Action Header (incoming from Java) is not empty, or apply WCF ServiceBehavior – AddressFilterMode.

Axis requires the SOAPAction:foo header. Don't ask me why, and 'foo' can be (as far as I can tell) anything, regardless of the service being invoked. But it will error if that's not there. So if you add that to your second try that might solve your problem.
YMMV, I've only had to deal with Axis-hosted Java services at a single client site, but ALL of them were like that.