I have a series of web pages that running off if an IIS (5.1) server.
The pages use VBscript in .ASP pages which display and populate a back end database.
These pages have been working 100% error free for years. I loaded a Microsoft tool (Visual Studio Express) to try it out. After loading the tool the IIS server started producing errors when the .asp pages tried to refresh. I think that the download tried to upgrade my web server. I removed the Visual Studio Express from my system. After numerous attempts to determine the source of the error (NOTE: No code was changed after the tool was loaded) I determined that the error happens when the characters “<><>” get posted during a refresh. NOTE: I use <><><><> in dynamically created pull downs as the default.
Ultimately the solution to the problem was simple, I just changed the default to be “---------“ in the pull downs versus “<><><><><>”
The Question is why did something that has worked 100% for over 9 years suddenly fail, and is there a configuration setting that I can change to have the server not error out on the <> characters.
A global search and replace will fix the problem, but this code sequence and subsequent logic are used in 100’s of places and that will be a tedious and time consuming task.
I know that ASP.Net has a ValidateRequest property which won't allow certain characters in certain places to prevent some hacking exploits. This is by default turned on. And I believe IIS 7 (possibly 6 also) treats all sites like an ASP.Net application to some degree (uses a web.config file). This isn't a verified fact, but I have web.config files show up even when I am testing an site with just .html files.
In ASP.Net you can change the ValidateRequest=true (default) property to ValidateRequest=false in the web.config file. That would probably stop the server side validation from happening and allow your defaults to go through.
Add <pages validateRequest="false" /> in system.web section of the web.config.
It's probably treating the angle brackets as potential cross-site scripting attacks - by default these days asp.net (I know you're using ASP, not ASP.NET) will throw an exception about a "Potentially dangerous postback" when you submit a string with angle brackets.
Is it possible that by installing VS (and therefore the DotNet framework) you've set the website that hosts these pages to use ASP.NET?
Have you tried removing the ASP.NET registration from that site? You can do this by running aspnet_regiis with the "-ua" switch. This command line tool can be found in:
C:\Windows\Microsoft.NET\Framework[vX.YYY]\
Where X.YYY is either 1.1.4322 or 2.0.50727
Related
I have a problem with caching of aspx and ascx files in one of my web applications on localhost (windows 7). If I make changes to one of these types of files, for example changing a hardcoded text, no browser picks up this change. I have tried ctrl+f5, and clearing the browser cache. Recompile doesn't help either since no code changes has been done. The only thing that helps is resetting IIS.
I have another web application running on the same IIS instance, where I don't experience this behavior. However, I can't figure out what the difference between those two applications is. I don't publish any files, the IIS sites are pointing directly to the files I edit in Visual Studio.
Any ideas?
For some reason this fixed it self when we went from Subversion to TFS this week.
I have tried googling and searching for this issue on SO - but have had little success - primarily because I am not sure whether I am searching right.
I am working on an ASP.Net Web Application Project (not website) using Visual Studio 2008, C# and Cassini for testing.
However, everytime I run the site, I get a URL such as:
http://localhost:8671/(S(saifdk55xyhalrqbstrtrdiw))/SubjectClassTeacher/Default.aspx
Even if I modify the URL and try to go to:
http://localhost:8671/SubjectClassTeacher/Default.aspx
I am redirected back to this URL.
The garbage value in the center: (S(saifdk55xyhalrqbstrtrdiw)) keeps changing every few times I compile and I have no idea why it gets injected or how to disable it.
Could anyone throw any light on this issue?
Primarily, I would like to know why this happens and how do I disable this.
Because this happens when I deploy the website on IIS as well.
Any help is appreciated.
Thank you.
This is a clever feature in ASP.NET* called cookieless sessions. It works by injecting your session ID into every URL, so ASP.NET can tell the difference between user A who visits a page, and user B who visits the same page. Normally this is accomplished with cookies, but this approach removes the dependency on the end-user having them enabled.
From MSDN:
...you don't have to change anything in your ASP.NET application to enable cookieless sessions, except the following configuration setting.
<sessionState cookieless="true" />
*The concept is not exclusive to ASP.NET, but it is baked into ASP.NET and - as you've discovered - can be turned on with no particular effort on the part of the developer.
Today we tried to put an ASP.NET application I helped to develop on yet another production machine. But this time we got a very weird error.
First of all, from all the ASP.NET pages, only Login.aspx was working. The rest just show a blank screen when they should have redirected to Login.aspx. The HTTP response is 200, but no content.
Even worse - when I try to enter the address of some inexistent ASPX page, I also get HTTP 200! Or, when I enter gibberish in some existing ASPX page code (which should have been accessible without login) I also get HTTP 200.
If I enter the name of some inexistent resource (like asdasd.jpg), I get the expected 404.
The redirect to login page is written manually in Global.asax. That's because the application has to use some alternate methods of authentication as well, so I can't just use Forms Authentication. I would suspect that Global.asax is failing, if not for the working Login page.
Noteworthy facts are also that this machine is both a Domain Controller and has SharePoint installed on it. Although the website in question is listed in SharePoint's exception list.
I would check the following:
Is the application within a virtual application or its own site and not just a virtual directory?
Does the application have it's own App Pool? If it does not then is the app pool shared by apps in a different .net version.
Is the .net version of the application the correct one? 1.1 or 2.0?
Do the files in the file system have the correct permissions to be accessed via IIS?
Have you performed an IIS Reset?
Create a stand alone test.aspx page within your folder that just displays the date/time and check it works.
Make this single test.aspx page perform an exception (eg. divide by zero) and see what the outcome is.
More information required.
What Op Sys?
What mode IIS running under?
What version of .Net?
What version of SharePoint?
(Why are you using your DC as a web host?)
Does it work on the other production machines you've deployed to?
If so what is different between this machine and the working ones?
Did you deploy the same way?
Are you sure your hitting the right machine?
Are you sure your hitting the right web site?
What ISAPI components are installed globally and for the web site?
Is .aspx mapped to the ASP.Net ISAPI filter?
Do you have any HTTP Modules or HTTP Handlers configured?
Can you change the global aspx to write out some messages so you can be sure the piece of code you interested in is reaching?
Anything coming up on the IIS log or the event logs?
Addition:
What version of .Net?
By the sounds of it the .jpg request is being dealt with by IIS directly which is why you get the 404, but the .aspx request is being dealt with by something else which except for you login page, is always returning 200.
Assuming .aspx is wired correctly to .Net the the order of processing is based on ISAPI filters (high to low then global before site), then the ASP.Net ISAPI Extension (sorry I said this was a filter earlier but it's actually an extension). Then we get into the ASP.Net pipeline based on your .Net configs, and calls the HTTP Application (which includes your global.asax code), any HTTP Modules followed finally by a HTTP Handler. Your ASP.Net web forms are just fancy HTTP Handlers.
However, the request can be responded to and terminated from any point.
Since your code works on other machines though, I'm tempted to point a finger at SharePoint if it isn't installed on the working machines. Is this SharePoint 2007? That is also an ASP.Net application (I don't think 2003 was).
I have a situation where I want to catch 404 errors fired by HTML pages (not just aspx pages) but I only have access to the web.config of the root folder of my website, and all sub directories (note, i don't have access to the actual IIS server and I cannot create applications or change settings)
So I did try the web.config customerrors on a subdirectory, and they do work, for ASPX pages only, not HTML pages, does anyone know why?
Note that the two answers above are correct for the usual case. However, IIS 6.0 and below can be configured to process HTML pages or anything else through ASP.NET. Also, IIS 7 has changed things radically - in effect, the ASP.NET pipeline is the IIS pipeline now, so that any piece of content is processed through any HttpModules.
Thus, in IIS 7 and above, anything you can configure for ASPX pages, you can configure for HTML pages.
You could have a look at the new routing capabilities for ASP.NET: http://msdn.microsoft.com/en-us/library/cc668201.aspx.
HTML pages are not parsed by IIS therefore are not affected by web.config settings. I am not aware of any way around this without configuring the settings in IIS.
To be a bit more specific than what Jeremy said, IIS maps different file extensions to different executables. By default it will be configured to let the .NET runtime handle .aspx files (in which case your web.config will be loaded & used), but it will serve the .html pages directly itself (& therefore fall back on its own 404 error handling).
Annoying, but I don't think there's much you can do beyond either having control of IIS, or by making your flat html pages into aspx pages (even though they contain no actual server-side content), to trick IIS into letting .NET handle them.
I am using VS 2008 with a very simple UpdatePanel scenario.
But i cannot get UpdatePanel to work and cant seem to find out why
I have in fact reverted to a very simple example to validate it is not my code:
http://ajax.net-tutorials.com/controls/updatepanel-control/
In this example I click on either button and both text links update.
I dont get any errors, the page just behaves like a normal ASPX page.
What things do i need to check. I've been googling this for an hour and not found what I need.
Edit: Works in Visual Studio web server but not in IIS
If it's working locally, but not when deployed to a remote server, that usually indicates that you're using ASP.NET 2.0 and the ASP.NET AJAX extensions aren't installed on the remote server.
If it's a server you have administrative control over, you can download the installer here: http://www.microsoft.com/downloads/details.aspx?FamilyID=ca9d90fa-e8c9-42e3-aa19-08e2c027f5d6&displaylang=en
If it's a web host, tell them to get their act together.
Another option would be to check your web.config. You could for example create an new Ajax enabled ASP.NET website from Visual Studio. This will generate a correct web.config. Copy over all non-ajax sections from your existing web.config and you're set. This worked for me.
-Edoode