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'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!
Related
Guys i have a web service in my project which running fine on localhost:
see here
The same project i upload on myasp.net hosting. but webservice is not running their
see here
am getting this error:
System.ComponentModel.Win32Exception: Access is denied
Dont know whats wrong with that, Can some one help me...
Update:
I gave Read/Write permission to the Root folder of the web site and its showing webservice now.But its not pasing the json data after calling from the ajax script..
As I can see on get reqesuts your web service returns me error Request format is unrecognized for URL unexpectedly ending in '/getStudentLoginData'.
One of the possible solutions is add to the web.config:
<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>
Answer based on that: https://stackoverflow.com/a/657315/1821692
It looks like there's something wrong with the hosting configuration. You may need to contact your hosting provider technical support. The error is saying that it's not able to run the C# compiler. This is not something you would normally encounter with a correctly configured server.
Do other types of dynamic requests work, .aspx, .ashx etc?
Does static content work correctly?
IIS Express is producing 403.14 Forbidden errors when a URL that would otherwise be handled through ASP.NET URL routing happens to correspond to a physical folder in my ASP.NET project. (The folder contains only code, and it's coincidental that the folder name happens to match the URL of a page; my URL structure is determined dynamically by a database, and users can edit that structure, so although I could just rename my project folder, in general I can't prevent this sort of collision occurring.)
This seems to be happening because the DirectoryListingModule steps in to handle the request, and then promptly fails it because directory browsing is disabled. I've tried removing this:
<system.webServer>
<handlers>
<remove name="StaticFile" />
<add name="StaticFile" path="*" verb="*"
modules="StaticFileModule" resourceType="Either" requireAccess="Read" />
</handlers>
</system.webServer>
That removes the default StaticFile handler configuration, which has modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule", and replaces it with a configuration that provides just the feature I want. (I want static file serving, but I have no need for directory listing or default documents in this app.) But the effect seems to be that IIS then produces a completely empty (0 byte) response (with a 200 status) when I hit the offending page.
So next, I tried configuring the StaticFile handler to handle only the specific physical folders that I want to make available:
<system.webServer>
<handlers>
<remove name="StaticFile" />
<add name="StaticFileCss" path="style/*.css" verb="*"
modules="StaticFileModule" resourceType="Either" requireAccess="Read" />
<add name="StaticFileScripts" path="Scripts/*" verb="*"
modules="StaticFileModule" resourceType="Either" requireAccess="Read" />
</handlers>
</system.webServer>
But when I hit the offending URL, this then produces a 404.4 - Not found error, with a message of The resource you are looking for does not have a handler associated with it.. (The Detailed Error Information on the error page says that we're in the IIS Web Core module, during the MapRequestHandler notification, the handler is Not yet determined, and there's an Error Code of 0x80070002, which is a COM HRESULT that corresponds to the Win32 ERROR_FILE_NOT_FOUND error.)
The mystifying thing is that it's not even bothering to ask ASP.NET whether it has a handler for it. IIS seems to be deciding all by itself that there definitely isn't a handler.
This only happens when there's a folder that matches the URL. All other resources with dynamically-determined URLs work just fine - IIS asks ASP.NET for a handler, ASP.NET's routing mechanism runs as normal, and if the URL corresponds to one of my dynamically defined pages, it all works fine. It's just the presence of a physical folder that stops this all from working.
I can see it's IIS doing this because I get one of the IIS-style error pages for this 404, and they have a distinctive design that's very different from the 404s produced by ASP.NET. (If I try to navigate to a URL that neither corresponds to a physical folder, nor to a dynamic resource, I get a 404 page generated by ASP.NET. So normally, IIS is definitely handing requests over to ASP.NET, but IIS is definitely getting in the way for these problematic resources.)
I tried adding this inside my <system.WebServer>, in case the problem was that IIS has decided that requests corresponding to physical folders do not meet the managedHandler precondition:
<modules runAllManagedModulesForAllRequests="true">
But that doesn't appear to help - it still doesn't get ASP.NET routing involved for URLs that correspond to physical folders. In any case, it would be suboptimal - I would prefer not to have managed handlers run for the content that I definitely want to handle as static content. I effectively want ASP.NET URL routing to be used as a backstop - I only want it to come into play if the URL definitely doesn't refer to static content.
I don't understand why ASP.NET isn't even asking ASP.NET what it thinks in this scenario. Why is it not calling into ASP.NET during the MapRequestHandler phase if there's a physical folder that happens to correspond to the URL?
When a physical file or folder with the same URL as the route is found, routes will not handle the request and the physical file will be served.
Althrough you can change this behavior by setting the RouteExistingFiles Property from the RouteCollection object to true.
Take a look at the MSDN page Scenarios when routing is not applied
Forgive me if this is basic. I've never made one before and can't seem to figure out why it's not working. I wrote a little handler to do some parsing on CSS files. I added this:
<system.web>
<httpHandlers>
<remove verb="*" path="*.css"/>
<add verb="*" path="*.css"
type="MyNameSpace.CssRelativePathHandler,CssRelativePathHandler" />
</httpHandlers>
</system.web>
Nothing ever happens. CSS files get parsed normally. No errors, nothing, the code never runs. What am I missing? Shouldn't this cause the handler to be used when *.css files are served? (I added the "remove" later, since I thought perhaps I needed to do that to override a built-in hander, again, no difference either way).
This is IIS 6. I added the IIS 7 code anyway (after searching for answers) but makes no difference.
<system.webServer>
<handlers>
<add name="CssHandler" verb="*" path="*.css"
type="MyNameSpace.CssRelativePathHandler,CssRelativePathHandler" />
</handlers>
</system.webServer>
You need to configure IIS6 to send requests for .css files to ASP.Net.
Had you been using IIS7, your <system.webServer> element would have done that for you, but IIS6 predates this.
For IIS 6 you need to have to tell it to send *.css files to ASP.NET.
Launch IIS Manager
Right-click on Default Web Site
Click on the Home Directory tab
Under Application Settings click on Configuration...
Add a new association for .css and map it to .NET executable:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
It sounds like you need to configure IIS to enable ASP.NET to execute the .css extension.
Phil Haack has a walkthrough on doing that (just replace .mvc with .css under the heading "Mapping .mvc to ASP.NET"):
http://haacked.com/archive/2008/11/26/asp.net-mvc-on-iis-6-walkthrough.aspx
Or you can set up a wildcard mapping in IIS 6:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/5c5ae5e0-f4f9-44b0-a743-f4c3a5ff68ec.mspx?mfr=true
I'd recommend going with the first method as doing the wildcard approach will send all requests to ASP.NET - so it has a more overhead.
PS: Further down Phil's post, he also lists "IIS6 Extension-less URL" and also covers the wildcard mapping method.
We are using the Intelligencia URLRewriting module for asp.net with version 2.0 of the framework and IIS6. Our URLs typically have no extension.
I understand that IIS6 cannot really deal with this situation without a blanket wildcard (which causes other problems).
However, it works! Sometimes. At other times (e.g. on one dev's machine, and on my machine when I point a different virtual directory at the app) it doesn't. By "it doesn't work" I mean the configured HttpModules never even get hit.
Can anyone explain this?
Thanks.
So it turns out what was happening was the following:
request comes in to (say) http://website/products/productid
IIS can't find this hence we get a 404
by chance we have a custom error page set up in IIS for 404s
this error page sticks the referring URL on the end of the 404 error.aspx page
so we get a redirect coming into asp.net along the lines of:
http://website/error.aspx?404;http://website/products/productid
our URLRewriting regexes were now set up in such a way that they discarded the error.aspx bit and dealt with http://website/products/productid as if it were the actual URL
so asp.net renders http://website/product.aspx?id=productid as requested!
I guess this could prove to be a useful kludge for someone, but we're moving to an isapi filter. One heads-up is that this will by default lead to a tight loop of redirects!
If you run a site using the Visual Studio development web server all requests will be handled by asp.net so your HttpModule will run.
On IIS6 this should not happen unless it is set up to forward the requests to asp.net.
Are you sure that when "it works" you aren't running under the Cassini development web server included in VS.NET ? Because extensionless wildcards do work under Cassini, which can be very confusing to say the least.
If you are using an IIS6 with ASP.net 4.0, you must specify and register the modules like this:
<system.web>
<httpModules>
<add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter"/>
not
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter"/>
</modules>
I've got a website running under ASP .NET 2/IIS7/Vista. I have a URL rewriting module which allows me to have extensionless URLs. To get this to work I have configured the system.webServer section of the config file such that all requests are forwarded to the aspnet_isapi.dll. I have also added the URL rewrite module to the modules section and set runAllManagedModulesForAllRequests to true.
When I start up the website and visit one of the pages that uses the URL rewriting, the page is rendered correctly. However if I then visit another page the site stops working and I get a 404 not found. I also find that my breakpoint in the URL rewriting module is not getting hit. It's almost as if IIS forwards the first request to the rewriter, but subsequent ones go somewhere else - the error page mentions Notification as being MapRequestHandler and Handler as being StaticFile.
If I then make a small change to the web.config file and save it, triggering the website to restart, I can then reload the page in the browser and it all works. Then I click another link and it's broken again.
For the record, here's a couple of snippets from the config file. First, under system.web:
<httpModules>
<add name="UrlRewriteModule" type="Arcs.CoopFurniture.TelesalesWeb.UrlRewriteModule, Arcs.CoopFurniture.TelesalesWeb" />
</httpModules>
and then, under system.webServer:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="UrlRewriteModule" type="Arcs.CoopFurniture.TelesalesWeb.UrlRewriteModule, Arcs.CoopFurniture.TelesalesWeb" preCondition="managedHandler" />
</modules>
<handlers>
<add name="AspNet" path="*" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="None" preCondition="classicMode,runtimeVersionv2.0,bitness32" />
</handlers>
<validation validateIntegratedModeConfiguration="false" />
</system.web>
The site is running under classic rather than integrated pipeline mode.
Does anyone out there have any ideas? I suspect my configuration is wrong somewhere but I can't seem to find where.
This is a bit of a long shot, but have you tried actually making the configuration changes inside of IIS?
I know that the web.config way is supposed to be 100% foolproof, but I've seen a few things where it helps to just configure it in IIS to get it working correctly.
You also may want to check out the new IIS7 rewrite module. you can read more about it here http://learn.iis.net/page.aspx/460/using-url-rewrite-module/, but chances are it will be more solid then your homegrown ISAPI filter
Try http://www.codeplex.com/urlrewriter it supports all the Apache mod_rewrite syntax and also supports Reverse Proxy.
If you're runnning in classic pipeline mode you don't need <system.webServer> section it is required for integrated mode
Enable wildcard script mapping
Open the IIS7 Manager and navigate to your site
Click on Handler Mappings
In the Action panel click on "Add Wild Card Script Map"
In the dialog point to aspnet_isapi.dll
Click Yes on the message box that asks you to confirm your mapping
In the action panel click on "View Ordered List" and move your WildcardScriptMap just before StaticFile Handler
This should bee enough.
I'm ashamed to admit this but it was a simple mistake by me :-(
In my URL rewriting module, the code to rewrite the request path was in the Init method, when it should have been inside an Application.BeginRequest handler. This explains why the rewriting worked only the first time the site was hit.
Sorry to have wasted your time people!