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!
i have an issue with url lengths in iis7. If you go to:
http://www.somesite.com/myaccount/login.htm?ReturnUrl=aa2Fmyaccounta2FdefaultaaspxadnoaauserSuppliedIdentifierahttpa3Aa2Fa2Faaaaaaamaapenidacoma2Fadnoaareturnatoasigahandleaa7B633942228855348748a7Da7BaRINLQa3Da3Da7DadnoaareturnatoasigaxSa2FFPGusD7UvskGqfkJq4QtEYjc4fSVFoa2F3sXNwCBteGOBJ8mipo7yLsuSk2hEgLogbzn6SthYb0wY3pBQM1OQa3Da3Daopenidaassocahandleaa7BHMACaSHA256a7Da7B4b051c2ba7Da7ddufPa2BAa3Da3Da7Daopenidaclaimedaidahttpa3Aa2Fa2Faaaaaaaaaopbnidacoma2Faopenidaidentityahttpa3Aa2Fa2Faaaaaaaabcpenidacoma2Faopenidamodeaidaresaopenidansahttpa3Aa2Fa2Fspec
The page will load fine but if you add one more character to the end it will throw an error. This might seem abit picky to you but it's stopping me from using open id on my login form since it returns a long url. One option i did consider was changing the requestFiltering, therefore in my web.config i have the following:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxQueryString="999999999" maxUrl="999999999" />
</requestFiltering>
</security>
</system.webServer>
But this did not resolve the issue. I'd appreciate it if someone could help. Thanks
nfplee - Are you using Ionics Isapi Rewrite Filter (IIRF) by any chance? I just ran into the same issue where long urls always returns a 404.
If I disable IIRF everything works fine.
This is a limitation of Windows and there is currently no workaround
See this StackOverflow article for more information:
ASP.NET url MAX_PATH limit
You may do something in web.config as follows.
<system.web>
<httpRuntime maxUrlLength="4000"/>
</system.web>
I get an error everytime I upload my webapp to the provider. Because of the customErrors mode, all I see is the default "Runtime error" message, instructing me to turn off customErrors to view more about the error.
Exasperated, I've set my web.config to look like this:
<?xml version="1.0"?>
<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>
And still, all I get is the stupid remote errors page with no useful info on it.
What else can I do to turn customErrors OFF ?!
This has been driving me insane for the past few days and couldn't get around it but have finally figured it out:
In my machine.config file I had an entry under <system.web>:
<deployment retail="true" />
This seems to override any other customError settings that you have specified in a web.config file, so setting the above entry to:
<deployment retail="false" />
now means that I can once again see the detailed error messages that I need to.
The machine.config is located at
32-bit
%windir%\Microsoft.NET\Framework\[version]\config\machine.config
64-bit
%windir%\Microsoft.NET\Framework64\[version]\config\machine.config
"Off" is case-sensitive.
Check if the "O" is in uppercase in your web.config file, I've suffered that a few times (as simple as it sounds)
In the interests of adding more situations to this question (because this is where I looked because I was having the exact same problem), here's my answer:
In my case, I cut/pasted the text from the generic error saying in effect if you want to see what's wrong, put
<system.web>
<customErrors mode="Off"/>
</system.web>
So this should have fixed it, but of course not! My problem was that there was a <system.web> node several lines above (before a compilation and authentication node), and a closing tag </system.web> a few lines below that. Once I corrected this, OK, problem solved. What I should have done is copy/pasted only this line:
<customErrors mode="Off"/>
This is from the annals of Stupid Things I Keep Doing Over and Over Again, in the chapter entitled "Copy and Paste Your Way to Destruction".
For Sharepoint 2010 applications, you should also edit C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\web.config and define <customErrors mode="Off" />
I tried most of the stuff described here. I was using VWD and the default web.config file contained:
<customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
<error statusCode="403" redirect="NoAccess.htm" />
<error statusCode="404" redirect="FileNotFound.htm" />
</customErrors>
I changed mode="RemoteOnly" to mode="Off". Still no joy.
I then used IIS manager, properties, ASP.Net Tab, Edit configuration, then chose the CustomeErrors tab. This still showed RemoteOnly. I changed this to Off and finally I could see the detailed error messages.
When I inspected the web.config I saw that there were two CustomErrors nodes in the system.web; and I have just noticed that the second entry (the one I was changing was inside a comment). So try not to use notepad to inspect web.config on a remote server.
However, if you use the IIS edit configuration stuff it will complain about errors in the web.config. Then you can rule out all of the answers that say "is there an XML syntax error in your web.config"
The one answer that actually worked to fix this I found here: https://stackoverflow.com/a/18938991/550975
Just add this to your web.config:
<configuration>
<system.webServer>
<httpErrors existingResponse="PassThrough"/>
</system.webServer>
<configuration>
You can generally find more information regarding the error in the Event Viewer, if you have access to it. Your provider may also have prevented custom errors from being displayed at all, by either overriding it in their machine.config, or setting the retail attribute to true (http://msdn.microsoft.com/en-us/library/ms228298(VS.80).aspx).
My problem was that i had this defined in my web.config
<httpErrors errorMode="Custom" existingResponse="Replace">
<remove statusCode="404" />
<remove statusCode="500" />
<error statusCode="404" responseMode="ExecuteURL" path="/Error/NotFound" />
<error statusCode="500" responseMode="ExecuteURL" path="/Error/Internal" />
</httpErrors>
I also had this problem, but when using Apache and mod_mono. For anyone else in that situation, you need to restart Apache after changing web.config to force the new version to be read.
If you're still getting that page, it's likely that it's blowing up before getting past the Web.Config
Make sure that ASP.Net has permissions it needs to things like the .Net Framework folders, the IIS Metabase, etc. Do you have any way of checking that ASP.Net is installed correctly and associated in IIS correctly?
Edit: After Greg's comment it occured to me I assumed that what you posted was your entire very minimal web.config, is there more to it? If so can you post the entire web.config?
Actually, what I figured out while hosting my web app is the the code you developed on your local Machine is of higher version than the hosting company offers you. If you have admin privileges you may be able to change the Microsoft ASP.NET version support under web hosting setting
We had this issue and it was due to the IIS user not having access to the machine config on the web server.
We also ran into this error and in our case it was because the application pool user did not have permissions to the web.config file anymore. The reason it lost its permissions (everything was fine before) was because we had a backup of the site in a rar file and I dragged a backup version of the web.config from the rar into the site. This seems to have removed all permissions to the web.config file except for me, the logged on user.
It took us a while to figure this out because I repeatedly checked permissions on the folder level, but never on the file level.
I had the same issue but found resolve in a different way.
-
What I did was, I opened Advanced Settings for the Application Pool in IIS Manager.
There I set Enable 32-Bit Applications to True.
Try restarting the application (creating an app_offline.htm than deleting it will do) and if you still get the same error message, make sure you've only declared customErrors once in the web.config, or anything like that. Errors in the web.config can have some weird impact on the application.
Do you have any special character like æøå in your web.config? If so make sure that the encoding is set to utf-8.
Is this web app set below any other apps in a website's directory tree? Check any parent web.config files for other settings, if any. Also, make your your directory is set as an application directory in IIS.
If you're using the MVC preview 4, you could be experiencing this because you're using the HandleErrorAttribute. The behavior changed in 5 so that it doesn't handle exceptions if you turn off custom errors.
You can also try bringing up the website in a browser on the server machine. I don't do a lot of ASP.NET development, but I remember the custom errors thing has a setting for only displaying full error text on the server, as a security measure.
I have just dealt with similar issue. In my case the default site asp.net version was 1.1 while i was trying to start up a 2.0 web app. The error was pretty trivial, but it was not immediately clear why the custom errors would not go away, and runtime never wrote to event log. Obvious fix was to match the version in Asp.Net tab of IIS.
Also make sure you're editing web.config and not website.config, as I was doing.
I have had the same problem, and the cause was that IIS was running ASP.NET 1.1, and the site required .NET 2.0.
The error message did nothing but throw me off track for several hours.
Make sure you add
right after the system.web
I put it toward the end of the node and didn't work.
If you are doing a config transform, you may also need to remove the following line from the relevant web.config file.
<compilation xdt:Transform="RemoveAttributes(debug)" />
Having tried all the answers here, it turned out that my Application_Error method had this:
Server.ClearError();
Response.Redirect("/Home/Error");
Removing these lines and setting fixed the problem. (The client still got redirected to the error page with customErrors="On").
I have had the same problem, and I went through the Event viewer application log where it clearly mention due to which exception this is happened. In my case exception was as below...
Exception information :
Exception type: HttpException
Exception message: The target principal name is incorrect. Cannot generate SSPI context.
at System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app)
at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)
The target principal name is incorrect. Cannot generate SSPI context.
I have just updated my password in application pool and it works for me.
It's also possible in some cases that web.config is not formatted correctly. In that case you have to go through it line by line before will work. Often, rewrite rules are the culprit here.
That's really strange. I got this error and after rebooting of my server it disappeared.
For me it was an error higher up in the web.config above the system.web.
the file blah didn't exist so it was throwing an error at that point. Because it hadn't yet got to the System.Web section yet it was using the server default setting for CUstomErrors (On)
None of those above solutions work for me. my case is
i have this in my web.config
<log4net debug="true">
either remove all those or go and read errors logs in your application folder\logs
eg.. C:\Users\YourName\source\repos\YourProjectFolder\logs