Home/ Questions/Q 6196969
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T03:44:17+00:00

We have a site running on MOSS 2007 which makes calls to custom web

  • 0

We have a site running on MOSS 2007 which makes calls to custom web service asmx methods on the same domain from the client.

At first everything works fine, but after a bit of time has passed the service will start to fail with:

http://[domain]/_layouts/error.aspx?ErrorText=Request format is unrecognized for URL unexpectedly ending in %27%2FIsSuspectWaterLevel%27.

Interestingly enough
http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx?op=IsSuspectWaterLevel
is still available, but a call to
http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx/IsSuspectWaterLevel
will fail as described.

We’ve found that “touching” C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\ISAPI\ web.config will bring the webservice back to life.

The asmx file lives at
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\ECan\MyECan_ComplianceWaterUsage.asmx

Any ideas of what might be going on here and how to resolve them?

Some extra detail:

App pool settings in case they’re useful: http://i51.tinypic.com/x51qw.png

The following web.config settings are present in the root and sub directory hosting the asmx:

  <system.web>
    <webServices>
      <protocols>
        <add name="HttpSoap" />
        <add name="HttpGet" />
        <add name="HttpPost" />
      </protocols>
    </webServices>
  ...
  </system.web>

We are calling the web service from javascript (jQuery). I’ve checked all the settings mentioned in this link and all match. I think calling from javascript may not be the culprit though as going directly to

[domain]/_vti_bin/Custom/CustomFunctionality.asmx/IsSuspectWaterLevel

with parameters supplied also fails with the same error – no javascript involved. Failing after a short period of time has passed, but works fine when web.config has just been “touched” again.

Thanks in advance for any help! Cheers, Gavin

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    An inelegant workaround to this issue that works for us: We’ve swapped out the web service asmx end point for a web handler ashx endpoint. This doesn’t suffer the same issue for some reason.

    I’m guessing from this that there’s some issue creeping in after a period of time which is causing urls to resolve incorrectly. I suspect that the / after the .asmx in the url is the curprit. The ashx endpoint implemented is working purely on url parameters and posted data.

    Obviously this work around won’t always be an option for others who might experience the same issue as we’re loosing a lot of the rich web service functionality that’s pre-baked in to an asmx endpoint.

    Unfortunately I won’t be able to test any other solutions that people might put forward from now on as we’ve moved away from the web service asmx approach. Sorry. Thanks for all the suggestions though – it’s been very much appreciated!

    • 0