2

I have a fairly strange(IMO) issue here with a webservice provided by a third party.

On calling the webservice on the live server, all works as expected. Calling it on a development setup, sometimes returns with a 503 - Service unavailable, other times it works. Intermittent.... Both of these tests are done from the same client, so I don't think its a network level problem.

Now, the strange thing is, if I place a breakpoint on the line before the webservice call, and step over the call, it works. Even running the code(F5) past this breakpoint allows it to succeed. Adding a System.Threading.Thread.Sleep(1000); before the call(to simulate a breakpoint, of sorts), doesnt have any effect.

I don't have access to the remote servers, I know its server 2003/IIS 6.0 though, and the company that provides the system the webservice interfaces with, claim there's no issue with their server / software.

So before I go seriously pointing the finger, anyone experienced anything like this before, or anything else I can try?

jasper
  • 3,424
  • 1
  • 25
  • 46

3 Answers3

1

In the end, this was caused by a issue on a transparent(ip spoofing) proxy, that sits upstream between my system and the remote system. The proxy was returning the 503, but under the guise of the target host.

I only managed to find this by fluke, how would I have identified this if I was to look for this type of issue, as theres nothing in the http headers /raw dump that jump out at me to point to this issue?

jasper
  • 3,424
  • 1
  • 25
  • 46
0

503 is an error from the server. It cannot be coming from the client.

If it's necessary to "prove" this, then you would need to watch the network traffic using Fiddler or something like it.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • I wouldnt need to get to that level to prove it, I just dont want to end up with egg on my face when I start pointing the finger, because I've missed something obvious. – jasper May 31 '11 at 13:20
  • @jasper: you'll sound much more convincing if you understand that all HTTP error codes come from the server, and all `500` codes are _due_ to the server. – John Saunders May 31 '11 at 14:44
0

It could be that the server does not accept multiple requests in a short period from the same client in order to protect itself from DoS attacks.

In such a case, clients are required to incorporate a throttling limit to their requests. So check again with your service provider.

SiN
  • 3,704
  • 2
  • 31
  • 36
  • nothing like this unfortunately(they claim), and if there was, i'd expect the same behaviour when i run on the live system. – jasper May 31 '11 at 13:15