0
votes

I have a perplexing issue. I have Web Service A (henceforth WSA), a 3.5 .Net WCF, which I have added a call to Web Service B (henceforth WSB) which is a 3.5 .Net ASMX. When running WSA in the client (SOAPUI or WCFStorm), the WSB call times out per the client timeout setting.

In the VS event viewer I can see that the call to WSB immediately throws two error 400s:

Exception thrown: 'System.Net.WebException' in System.dll ("The remote server returned an error: (400) Bad Request."). Exception thrown: 'System.Net.WebException' in System.dll ("The remote server returned an error: (400) Bad Request.")

No reason is given. What is just as puzzling to me is the error doesn't go to my catch. When I debug and I hit the line of code that calls WSB, it's like a reset. No further code gets executed and no error is thrown by my WSA.

If I call WSB directly, it works. So nothing is wrong with WSB. At suggestion of a coworker, I took the code specific to my change and put it in a stand-alone service. I literally C&P the code and configs setting specific to me and adjust namespaces and class names. Lo and behold it works. My stand-alone web service called WSB just fine and get the data I expect.

A coworker and I checked the logs (IIS log for the service and the HTTPERR log) on the IIS server that WSB resides on to see if there was any mention of the 400 error. We found none.

So we are kind of perplexed at this point. The only thing we can think of is perhaps something in the web config might be interfering but have no idea what it could be.

If you have any suggestions of where else to look that would be helpful.

And it would be nice to know why it isn't falling into my error handler.

Thanks.

Update: It was requested I add config and code. I don't think it will help honestly and it is pretty straightforward. I can't put the real code due to company reasons but it is basically this:

In web config:

    <configuration>
    <appSettings>
    <add key="endpointUrl" value = "someurl" />
    </appSettings>
    .
    .
    .
     <applicationSettings>
        <MyService.Properties.Settings>
          <setting name="MyService_TheirService"
            serializeAs="String">
            <value>someurl</value>
          </setting>
    </MyService.Properties.Settings>
  </applicationSettings>

Even though the data is super small I did try making large reader settings and such:

<binding name="CustomHtttpBinding" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" closeTimeout="01:50:00" openTimeout="01:50:00" sendTimeout="01:50:00" receiveTimeout="01:50:00" >
          <readerQuotas maxDepth="128"
             maxStringContentLength="8388608"
             maxArrayLength="2147483646"
             maxBytesPerRead="4096"
             maxNameTableCharCount="16384" />
        </binding>

Code:

using MyService.TheirService
.
.
.
var theirURL = ConfigurationManager.AppSettings["endpointUrl"];

var oSvc = new TheirServiceObject
{
    Url = theirURL
};

int numberIneed = oSvc.SomeMethod();

That last line is where it throws the 400.

UPDATE 2:

A colleague show me how to use Fiddler. And I can now see that the request to WSB is absolute garbage.

xڭ s 6 mr!!u \ .3 5'3 G QOH>Iп kX M3 ~vY ) X e Z w ~ :jv -ݴwڽHb Yqv A :(Q Z; >9W O0g 6 .ɖVlU Ţ 8Z < ( t eSv U]r R $N \

Some odd encoding? At least it's another clue.

1
Posting some code and config sections would be helpful, otherwise the only answers you most likely will get our very general and probably non-helpful. - Tim

1 Answers

0
votes

Wanted to let you know this problem was solved. Another Dev that had worked on this service before but no longer just happened to walk by and I said "Hey! Look at this!"

They saw the garbage request data and said "That looks like compression. Look up compression in the project."

Turn out there was a custom compression component that was compressing the outgoing data of the service and you needed to add 2 lines of code to decompress. After adding those lines to the top of my method everything immediately worked.

The lesson here is if your project is doing some weird stuff that defies reason, try and find as many people as you can that worked on it before even if they aren't working on it anymore.