WCF "HTTP 400 - bad request" error message if Content Length field in request header is 0 - by Eunan Muldoon

Status : 

  Postponed<br /><br />
		Due to current priorities, the product team decided to postpone the resolution of this item.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 481518 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 8/7/2009 3:59:18 AM
Access Restriction Public


This bug is applicable to the .net framework, but I can't see any other way of submitting a bug on .net so I'm posting it here.

Note - this bug looks identical to an IIS related bug (http://support.microsoft.com/kb/293131)

The bug seems to have been introduced by one of the following services packs,
.net 2.0 SP2 or .net 3.0 SP2. The bug does not exist when I've got 2.0 SP1, 3.0 SP1  & 3.5 installed. The bug occurs every time a zero length message is received by my WCF application.
Sign in to post a comment.
Posted by J. Schnauffer on 1/17/2012 at 5:02 AM
Dear Sir or Madam,

here currently experiencing some similar problem in a WCF self-hosted scenario where a WCF 4.0 Routing Srvice is to be added in between existing clients and ASMX (Axis) Services.

Fiddler protocols the request as:

GET http://machine/service HTTP/1.1
Host: machine
Connection: Keep-Alive

... and the response is

HTTP/1.1 400 Bad Request
Content-Length: 0
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 17 Jan 2012 12:57:01 GMT

Service Trace Log contains:

<ExceptionType>System.ServiceModel.ProtocolException, System.ServiceModel, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089</ExceptionType>
<Message>There is a problem with the XML that was received from the network. See inner exception for more details.</Message>
at System.ServiceModel.Channels.HttpRequestContext.CreateMessage()
at System.ServiceModel.Channels.HttpChannelListener.HttpContextReceived(HttpRequestContext context, Action callback)
at System.ServiceModel.Channels.SharedHttpTransportManager.OnGetContextCore(IAsyncResult result)
at System.ServiceModel.Channels.SharedHttpTransportManager.OnGetContext(IAsyncResult result)
at System.Runtime.Fx.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
at System.Net.ListenerAsyncResult.WaitCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
<ExceptionString>System.ServiceModel.ProtocolException: There is a problem with the XML that was received from the network. See inner exception for more details. ---> System.Xml.XmlException: The body of the message cannot be read because it is empty.
--- End of inner exception stack trace ---</ExceptionString>

Neither an Inspector nor a message filter is able to get informed about that incoming request before above mentioned ProtocolException gets raised.

Posted by Microsoft on 9/8/2009 at 5:55 PM
Thanks for bringing this up. I was able to repro this issue and this seems like a bug. I have created a bug in our internal database to track the fix for this. It is good that you mentioned the scenario you have becuase otherwise I think it is uncommon for a client to send a zero content length message. We will consider a fix for this in a future release. I am closing this bug as 'Postponed' for now.
Piyush Joshi
[Program Manager, WCF]
Posted by Eunan Muldoon on 9/1/2009 at 8:30 AM
Hi Piyush,

sorry for the delay in responding my profile wasn't completed correctly & I didn't receive any notification when comments were added.

It is indeed an empty SOAP body. The reasoning behind this type of message is an ASDL protocol called TR-069. This protocol states that an empty message sent from a client to a server indicates that the client has finished its transactions and it is now safe for the server to send any administration messages it may have. Effectively a handshake message stating that it is now ok to proceed.

Here's the svctraceviewer trace of the empty SOAP message.

<E2ETraceEvent xmlns="http://schemas.microsoft.com/2004/06/E2ETraceEvent">
<System xmlns="http://schemas.microsoft.com/2004/06/windows/eventlog/system">
<SubType Name="Information">0</SubType>
<TimeCreated SystemTime="2009-09-01T14:51:15.6524368Z" />
<Source Name="System.ServiceModel.MessageLogging" />
<Correlation ActivityID="{00000000-0000-0000-0000-000000000000}" />
<Execution ProcessName="ZMS" ProcessID="2460" ThreadID="5" />
<Channel />
<MessageLogTraceRecord Time="2009-09-01T15:51:15.6368116+01:00" Source="TransportReceive" Type="System.ServiceModel.Channels.NullMessage" xmlns="http://schemas.microsoft.com/2004/06/ServiceModel/Management/MessageTrace">
<Content-Type>text/xml; charset=utf-8</Content-Type>

Also here's the Wireshark TCP trace of this message,

User-Agent: gSOAP/2.7
Content-Type: text/xml; charset=utf-8
Content-Length: 0
Connection: keep-alive
SOAPAction: ""

Hopefully this clarifies things for you. If not then please email me directly.
Posted by Microsoft on 8/20/2009 at 11:18 PM
Hi Eunan, I think I get now what you are saying after rereading what you described. You are essentially passing an empty "HTTP" body itself rather than an empty SOAP body as the description seemed to suggest and which I earlier tried. Could you please describe me your scenario so that we can determine if this is something we would like to support. It does seem unnatural to me to pass a zero payload Http request to a service. Why would someone do it?
Piyush Joshi
[Program Manager, WCF]
Posted by Microsoft on 8/20/2009 at 10:40 PM
Hi Eunan,
Thanks for your input. I attempted something which does not led me to the behavior you observed.
I am trying the following on the client side for sending the message with empty body -
Message message = Message.CreateMessage         (MessageVersion.Soap11, "DoSomething", "");
And I am getting an HTTP 500 with the exception message:
"Error in deserializing body of request message for operation 'DoSomething'. OperationFormatter encountered an invalid Message body. Expected to find node type 'Element' with name 'DoSomething' and namespace 'http://tempuri.org/'. Found node type 'Element' with name 'string' and namespace 'http://schemas.microsoft.com/2003/10/Serialization/'" which is expected because for the WCF engine to route the message to the correct method, it should contain a valid 'Action' in the message based on which the routing is done.
Let me know if all of this makes sense. You can also attach a repro to this bug to expedite investigation if I am going at a tangent :-)
Posted by iamveritas on 8/20/2009 at 4:16 PM
I am seeing something similar, I have a service bound through a WebHttpBinding to http://localhost:555/serviceroot/baseaddress
now when I hit it with fiddler I get a 400 bad request which doesn' tmake any sense, it is a basic GET nothing bad about it.
Did anyone looked into this, is there a workaround?
Any help would be appreciated.
Posted by Eunan Muldoon on 8/12/2009 at 3:25 AM
It is self hosted.
Posted by Microsoft on 8/11/2009 at 1:49 PM
Please also tell me which OS you are running on the IIS version if you are web hosting.

Posted by Microsoft on 8/11/2009 at 1:47 PM
Thanks for reporting this issue. You may be running into a known problem. Is your service web hosted or self hosted?

Posted by Microsoft on 8/10/2009 at 1:35 AM
Thanks for your feedback. We are routing this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team