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

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 fil开发者_StackOverflow社区e 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'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

It has been awhile since I have touched Sharepoint so this is a shot in the dark. If I remember correctly modifying anything in the web.config will restart the website in IIS. So what you may be seeing is IIS restarting the website that hosts the webservice putting it back into a good state.

Do you have the following in the web.config for the web application?

<webServices>
   <protocols>
    <add name="HttpGet"/>
    <add name="HttpPost"/>
   </protocols>
</webServices>

This is a strange problem and hard to diagnose due to the number of occcurances of the 12 hives web.config protocols issue which would appear to resolve 99% of the cases of this issue.

There is another issue called URL rewriting that will cause this problem.

Some reverse proxy devices can modify the path of a request (the portion of the URL that comes after the hostname and port number) in such a way that a request sent by the user to http://www.contoso.com/sharepoint/default.aspx, for example, is forwarded to the Web server as http://sharepoint.perimeter.example.com/default.aspx.

This is referred to as an asymmetrical path. Windows SharePoint Services 3.0 does not support asymmetrical paths. The path of the URL must be symmetrical between the public URL and the internal URL. In the preceding example, this means that the "/sharepoint/default.aspx" portion of the URL must not be modified by the reverse proxy device.

Even more depressing is that microsoft knows about this and actively refuses to support it.

Ref: URL Rewrite + SharePoint = No Support

Also : SharePoint, url rewriter, WebServices

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!