locked
Sharepoint denying access to asmx methods RRS feed

  • 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.

    On the live site requests are getting redirected to the following url:

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

    We've added the following to the sites web.config without any joy:

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

    Interestingly enough we don't have this issue on the test server which is supposed to be pretty identical to the live server.

    Any ideas to what other variable might be at play here?

    While a call to

    http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx/IsSuspectWaterLevel

    fails, I can still access

    http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx?op=IsSuspectWaterLevel

    though it fails when I invoke the message in the same way.

    I wonder if this helps shed more light on the issue?

    Thanks in advance for any ideas, Gavin

    Update:

    I've just observed the same error on the dev server. Removing the apps dll from GAC and then re-copying it in solved the issue. The live server tested fine with initial deployment so perhaps there's an issue with Sharepoint loosing some reference over time? Clutching at straws as very confusing behaviour!

    Another Update:

    It seems everytime I touch (open and save) the web.config file in 12 Hives the problem is fixed again for a period, but after a while the problem comes back. I wonder if it's anything to do with the app pool being recycled?

    C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\ISAPI\web.config


    www.gavinharriss.com


    • Edited by gavinharriss Friday, July 8, 2011 3:12 AM More evidence added
    Tuesday, July 5, 2011 8:53 PM

Answers

  • 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.


    www.gavinharriss.com
    • Marked as answer by gavinharriss Wednesday, July 27, 2011 9:13 PM
    Wednesday, July 27, 2011 9:13 PM

All replies

  • Hi Gavin

    Changes that you make to any of the web.config files that are built into SharePoint, or that are created when a SharePoint Web application is created, may be overwritten when you install updates or service packs for SharePoint , or when you upgrade an installation to the next product version. For this reason, we recommend that you not directly edit these files.

    Make changes to web.config settings using either the method described in How to: Create a Supplemental .config File or the method described in How to: Add and Remove Web.config Settings Programmatically. With either method, your custom settings can be reapplied post-upgrade.

    I have an example of using the supplemental approach for Ajax configuration on codeplex http://ajaxwebconfig.codeplex.com/...

     

    -Ivan

     


    Ivan Sanders My LinkedIn Profile, My Blog, @iasanders.
    Sunday, July 17, 2011 9:26 PM
  • Hi Ivan,

    Thanks for the info - something for us to keep in mind for the future.

    Any idea what might be causing the issues discussed though? Our custom code isn't being overwritten as it starts to work again once I "touch" the web.config file. Obviously we're looking for a more elegant solution that keeping touching the web.config file to keep the web service up and running.

    Cheers, Gavin


    www.gavinharriss.com
    Monday, July 18, 2011 11:41 PM
  • 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.


    www.gavinharriss.com
    • Marked as answer by gavinharriss Wednesday, July 27, 2011 9:13 PM
    Wednesday, July 27, 2011 9:13 PM