Home Dashboard Directory Help
Search

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


Status: 

Resolved
 as Fixed Help for as Fixed


2
0
Sign in
to vote
Type: Bug
ID: 488144
Opened: 9/4/2009 7:09:32 AM
Access Restriction: Public
0
Workaround(s)
view
1
User(s) can reproduce this bug

Description

I'm creating a new issue because the previous issue was closed prematurely without getting my feedback on how to reproduce it (ID: 481518).

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.
Details
Sign in to post a comment.
Posted by Microsoft on 7/20/2010 at 11:14 AM
Hi Eunan,
We are also tracking the same bug as http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=573225 here and are also working with the Microsoft support team who is helping you on this issue. I'll resolve this bug as a duplicate of the other connect bug to make sure that we are capturing all the investigatiion via one bug.
Thanks.
Posted by Eunan Muldoon on 7/14/2010 at 1:58 AM
Yes the repro works correctly with .net 3.5, .net 3.0 SP1 and .net 2.0 SP1 and fails with error code 400 when .net 3.5 SP1 is installed. It fails 100% of the time.
Posted by Eunan Muldoon on 7/14/2010 at 12:46 AM
Sorry, I've just discovered it in the collapsed "Details" section.
Posted by Eunan Muldoon on 7/14/2010 at 12:44 AM
I can't see where the repro is attached?
Posted by Microsoft on 7/13/2010 at 11:11 AM
Hi,
We have reactivated the bug internally for further investigation. I am also working with the Microsoft support team who are working with the customer directly to come up with a workaround. We didn't receive a standalone repro for this issue so we have the attached repro we are using. Can you confirm that this works at your end on the pre-regression platform and throws 400 on the post-regression platform?
Thanks,
Piyush.
Posted by Eunan Muldoon on 7/8/2010 at 9:11 AM
Hi Piyush,

the bug can be avoided on our XP Professional operating system if .net 3.5, .net 3.0 SP1 and .net 2.0 SP1 are installed. When you stated that you still had the bug "on a Vista machine with 3.0 installed" I'm unsure what .net configuration you meant by this? If you configure your PC with the above .net configuration the bug should disappear.

I cannot attach code to reproduce the problem as the client is running a gSOAP stack on an embedded Linux operating system.

I can guarantee that this bug only appeared when .net 3.5 SP1 was installed. We were running quite happily for ~12 months with no problems at all. Please also look at http://support.microsoft.com/kb/293131 since it also gives identical behaviour to what we see once .net 3.5 SP1 is installed and might give you some further information regarding the source of the bug.
Posted by Microsoft on 7/7/2010 at 10:10 AM
Hi Eunan,
We are having discussions internally to reconsider this bug if this is a regression. However, I still get this error when I run the repro on a Vista machine with 3.0 installed. I know this is a simple repro but to avoid any confusion, is it possible to attach a repro which you are using to the bug? And also let us know exactly which OS and framework is it working without the HTTP 400 error? I think you will understand that if we fix this even if this was not a regression, it will introduce a new behavior unexpected for other customers.
Thanks,
Piyush.
Posted by Eunan Muldoon on 6/29/2010 at 9:21 AM
Piyush,

we have waited approximately 10 months for a fix for this acknowledged bug (which does not exist in .net 3.5) and now the resolution is now marked as "Fixed" but the problem has clearly not been fixed.

This is completely unacceptable as the outcome means that we can never upgrade any of our .net service packs as they will introduce this bug. I accept that this may not be a common problem for many of your customers but for our company it is essential that we either have a hot-fix or at least a workaround that also lets us upgrade our .net service packs in future. Otherwise we have no option but to move away from a Microsoft environment to one that we can control more closely ourselves.

Can you at least provide a workaround that will also let us upgrade the .net service packs?
Posted by Microsoft on 6/23/2010 at 5:23 PM
Hi Eunan,
We triaged this issue internally and we have decided to 'Won't Fix' this one since we do not believe that this is a common customer scenario.
I will suggest that if you feel that this issue is critical/blocking then you contact PSS(http://support.microsoft.com/kb/295539/en-us) and provide them with business justifications for needing to address this issue.
Thanks,
Piyush.
Posted by Eunan Muldoon on 6/18/2010 at 1:13 AM
In which release is this fixed & when will it be available? I cannot see this information listed anywhere.
Posted by adrianmarsh-ubi on 5/28/2010 at 11:00 AM
Piyush,

Do you have an idea as to when this fix will be released?
Posted by Microsoft on 9/16/2009 at 12:36 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.
Thanks.
Piyush Joshi
[Program Manager, WCF]
Posted by Microsoft on 9/6/2009 at 8:15 PM
Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com/)
Posted by Eunan Muldoon on 9/4/2009 at 7:11 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">
<EventID>0</EventID>
<Type>3</Type>
<SubType Name="Information">0</SubType>
<Level>8</Level>
<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 />
<Computer>UBIQ-DELL19</Computer>
</System>
<ApplicationData>
<TraceData>
<DataItem>
<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">
<HttpRequest>
<Method>POST</Method>
<QueryString></QueryString>
<WebHeaders>
<SOAPAction>""</SOAPAction>
<Connection>keep-alive</Connection>
<Content-Length>0</Content-Length>
<Content-Type>text/xml; charset=utf-8</Content-Type>
<Host>192.168.50.178:8082</Host>
<User-Agent>gSOAP/2.7</User-Agent>
</WebHeaders>
</HttpRequest>
</MessageLogTraceRecord>
</DataItem>
</TraceData>
</ApplicationData>
</E2ETraceEvent>

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

POST /ZMS HTTP/1.1
Host: 192.168.50.178:8082
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 Eunan Muldoon on 9/4/2009 at 7:10 AM
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?
Thanks.
Piyush Joshi
[Program Manager, WCF]
Posted by Eunan Muldoon on 9/4/2009 at 7:10 AM
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 :-)
Thanks.
Posted by Eunan Muldoon on 9/4/2009 at 7:10 AM
The application is self-hosted.
Sign in to post a workaround.