Custom Sharepoint webservice requires web.config to be "touched" regularly

Question

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

I cross-posted this problem here social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/… in case any of the extra detail supplied is useful. — Gavin
And yet another cross-post with more info still (including app pool settings) - forums.asp.net/p/1698836/4506161.aspx/… — Gavin
I'm wondering if url routing is the issue? It seems after some time has passed that possibly the / after the .asmx might not be getting resolved correctly? — Gavin

Chris Chris · Accepted Answer · 2012-04-14T12:36:33

I'm currently working on the same problem, and I think you barked the wrong tree.

The problem is, that in the ISAPI folder of SharePoint is a web.config with the following lines:

<webServices>
    <protocols>
        <remove name="HttpGet"/>
        <remove name="HttpPost"/>
        <remove name="HttpPostLocalhost"/>
        <add name="Documentation"/>
    </protocols>
</webServices>

The problem is, that the desired protocols POST and GET will be removed for the entire ISAPI folder and its subfolders. I also tried to reactivate the protocols via

<location path="[Path to my Web Service].asmx" allowOverride="false">
    <webServices>
        <protocols>
            <add name="HttpGet"/>
            <add name="HttpPost"/>
        </protocols>
    </webServices>
</loaction>

in different places (machine.config, web.config of root folder, web.config app.config, ...), but it didn't last.

The only thing that worked, was, to change the "remove" items in the web.config of the ISAPI folder to "add" items. But this has the nasty side effect, that the built-in web services, like "Lists.asmx" throw errors if you try to request their documentation pages... If you can live with that, this would be your solution. I can't, so I still try to figure out a way to make my

<add name="protocol">

items persistent.

By the way: Also adding lockItem="true" to the <add/> items didn't do the trick...

Chris

Custom Sharepoint webservice requires web.config to be "touched" regularly

5 Answers