[Bug]: Soap11WSAddressingAugust2004 failing

[erviem99]

Duplicate ?

• [X] I have searched issues/discussions and did not find other issues/discussions reporting this bug.

Product version

1.5.1

Describe expected behavior

SOAP message should reach endpoint

Describe actual behavior

Internal error in CoreWCF while processing SOAP request

Which binding

CustomBinding

security

None

Which .NET version

.NET 6

Which os platform

Windows

Code snippet used to reproduce the issue

CustomBinding customBindingSoap11 = new CustomBinding(new BasicHttpBinding());
                var encoding = customBindingSoap11.Elements.Find<TextMessageEncodingBindingElement>();
                encoding.MessageVersion = MessageVersion.Soap11WSAddressingAugust2004;
...
                // Add the Service
                builder.AddService<SomeService>(serviceOptions =>
                {
                })
                // Add a BasicHttpBinding endpoint
                .AddServiceEndpoint<SomeService, ISomeService>(customBindingSoap11, "/someendpoint.asmx", endpoint =>
                {
                })

Stacktrace if any

fail: Microsoft.AspNetCore.Server.Kestrel[13]
      Connection id "0HMVB55JE925V", Request id "0HMVB55JE925V:00000002": An unhandled exception was thrown by the application.
      System.ObjectDisposedException: Message is closed.
         at CoreWCF.Channels.BufferedMessage.get_Properties()
         at CoreWCF.Channels.AspNetCoreReplyChannel.HandleRequest(HttpContext context)
         at CoreWCF.Channels.RequestDelegateHandler.HandleRequest(HttpContext context)
         at CoreWCF.Channels.ServiceModelHttpMiddleware.InvokeAsync(HttpContext context)
         at CoreWCF.Channels.MetadataMiddleware.InvokeAsync(HttpContext context)
         at Microsoft.AspNetCore.Watch.BrowserRefresh.BrowserRefreshMiddleware.InvokeAsync(HttpContext context)
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)

[mconnew]

The message gets closed when the Message has been consumed. This can happen if you have something like a message inspector which reads the message body. If you have an extensibility code doing this, you should create a BufferedCopy first, then from the BufferedCopy, make two messages, one to replace the original, and one to work on yourself. If you don't have any extensibility doing something like this, let me know.

[erviem99]

I have commentet out everything I can think of including serilog and any endpoint behaviours and I still get the error:

fail: Microsoft.AspNetCore.Server.Kestrel[13] Connection id "0HMVV2MQF205B", Request id "0HMVV2MQF205B:00000002": An unhandled exception was thrown by the application. System.ObjectDisposedException: Message is closed. at CoreWCF.Channels.BufferedMessage.get_Properties() at CoreWCF.Channels.AspNetCoreReplyChannel.HandleRequest(HttpContext context) at CoreWCF.Channels.RequestDelegateHandler.HandleRequest(HttpContext context) at CoreWCF.Channels.ServiceModelHttpMiddleware.InvokeAsync(HttpContext context) at Microsoft.WebTools.BrowserLink.Net.BrowserLinkMiddleware.InvokeAsync(HttpContext context) at Microsoft.AspNetCore.Watch.BrowserRefresh.BrowserRefreshMiddleware.InvokeAsync(HttpContext context) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)

[CezaryKlus]

Hi, take a look at this one #1356

[jecook]

I am getting a similar error when I send a request message that does not have an action matching the HTTP SOAP action. In old WCF I would get the exception "The SOAP action specified on the message, '', does not match the HTTP SOAP Action", but in CoreWCF that error gets hidden.

It looks to me as though the problem lies in the AspNetCoreReplyChannel.HandleRequest method. This call returns a non-null message and a non-null exception:

(Message requestMessage, Exception requestException) = await httpInput.ParseIncomingMessageAsync();

Then this closes the message because of the exception:

requestContext.SetMessage(requestMessage, requestException);

Then this throws the System.ObjectDisposedException "Message is closed" when getting the Properties because the message is disposed:

if (requestMessage != null)
{
    requestMessage.Properties.Add("Microsoft.AspNetCore.Http.HttpContext", context);
}

It looks like this was introduced by @mconnew in https://github.com/CoreWCF/CoreWCF/commit/edd5d1747d53bd037299fa245cea6d4b907be273.

There are some simple options that spring to mind:

1. Also check for a null exception before adding the property.
2. Also check the state of the message is not Closed before adding the property.
3. Add the property before the SetMessage call closes it.

I have checked that any of these options results in the correct fault being returned in the response.