I am moving old asp.net website from windows 2003 to windows 2008 R2.
Some pages have '&' in url and it works fine on 2003 but on 2008 any '&' before '?' gives 'Bad Request'.
Those pages have serious impact on website popularity, 7% of all visits start here, so it is important to handle them properly without changing url.
Any ideas how to handle such urls on iis7 / asp.net 2.0?
PS: validateRequest doesn't work
Try adding the following in web.config:
<system.web>
<httpRuntime requestPathInvalidCharacters="*,:,\" />
...
</system.web>
Notice that I have removed & from the list of invalid characters in a path.
Here's a link that may get you where you want to to be, but if you read the details, I'd personally add this to the "do so at your own risk" category...take Microsoft's word for at least one of the "fixes":
Important If you enable this fix, you increase the attack surface of the application. You should not enable this fix unless the application requires it.
DWORD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET VerificationCompatibility = 1
The others should be self-explanatory on risk just by the setting names (e.g. AllowRestrictedCharacters, ValidateRequest=False):
That said, you should think about updating those "legacy" urls and do a 301 Permanent redirect to account for your SEO/popularity...
Related
I have tumbled with a problem with IIS on the Windows Server 2008 R2 for some time now. I have a website that needs to be moved to this server.
What happend when we move the solution is that every URL that have special character as æ, ø, å, á or spaces (%20) etc. will not work, hanging and lastly times out. The problem occours both on images and files (ashx, gif, jpg). Everything looks like it's being URL encoded.
We have no issue at all on the old server on this matter.
Here is some example of the issue:
http://biva-search.workingpropeople.com/~/media/Flash%20-%20og%20alternativer%20740x188/TLFlash/Timberman.ashx?w=740&h=231
http://biva-search.workingpropeople.com/~/media/170x120/Boerne_t%C3%A6pper.ashx?mw=170
I'm sure it is some crazy settings I missed out and I hope someone here can help me out :)
Kind regards,
Niels
Not sure of the IIS issue/solution, afaik special characters are not allowed in URLs, but the "Sitecore" way of resolving this is character replacement via config. This article explains config change required: SEO-friendly URLs in Sitecore
But essentially you need to add more encodenamereplacements in Sitecore config:
<encodenamereplacements>
...
<replace mode="on" find="æ" replaceWith="a" />
<replace mode="on" find="ø" replaceWith="o" />
</encodenamereplacements>
There is another thread with a similar issue: Sitecore issue on replacing danish characters in url
Well i have a http handler that is set up like this
<add name="DocumentHandler" verb="*" path="/LinkDocumentHandler/*" type="MyTestProject.LinkDocumentHandler, MyTestProject" />
(Remove name in IIS 6 and move it to the right section)
This works great in my VS webserver all requests that are going to the directory LinkDocumentHandler are handled by the handler..
Now when i come to IIS 6.0 this did not work so i googled a bit and found out that i have to define what file types IIS 6.0 will pass to asp.net well i can't predict all of them so that would not be so nice..
I tried to change /LinkDocumentHandler/* to /LinkDocumentHandler.aspx/* but that did not help..
So is there any way to force IIS 6.0 to pass all file requests with that sub dir to my http handler??
In IIS I added a Wildcard and unchecked "check if file exists" and it just worked (used the same dll that .aspx uses)!
This is very difficult to do in IIS 6, what you really need to do for this is write an ISAPI filter. Beyond that, IIS mappings are pretty much controlled by the file extension so it's very difficult to get it to pass all requests to asp.net.
There's a similar discussion here, where it appears the OP might have found a "partial" solution.
If I try to use the new maxRequestPathLength settings in an ASP.NET application it does not work. I get an unrecognized attribute error. I've tried using both ASP.NET Integrated and Classic application pools in IIS 7. What is also funny is that if you search for maxRequestPathLength on MSDN it is no where to be found in the documentation except in the list of new features for ASP.NET 4. What gives?
Apparently this setting name was changed and move to the registry under "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters." The name is UrlSegmentMaxLength. The default value is 260. This particular setting limits the amount of characters allowed in each path segment of a URL. In https://stackoverflow.com/questions, "questions" would be a path segment.
Documentation for this can be found in the Microsoft knowledge base article on http.sys registry settings.
I've been struggling with this and with help of this post en several other forum post made it work for me. Here is my log and findings:
To allow longer url's then default, just change this in your web.config (.NET 4.0 and up)
<httpRuntime maxUrlLength="1024" relaxedUrlToFileSystemMapping="true"/>
Note: if relaxedUrlToFileSystemMapping is set te to false, urlsegments larger then 260 wil fail with an IOException PathTooLongException:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
To allow longer url segments then the default 260 add/change this registry setting:
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters."
The name is UrlSegmentMaxLength. (Dword)
And most importantly after changing this setting. REBOOT your machine.
I've tried IIS-Reset and net stop http / net start http, but this did not make the change effective.
Currently i have 2 machines available.
My local dev-machin (Windows 7 / IIS 7.5) and a dev-server (Windows 2003 / IIS 6.0)
Both took a reboot to make the changes effective.
This had me foxed for a little while. The way to do this in .NET 4 is like this:
<httpRuntime maxUrlLength="1024" relaxedUrlToFileSystemMapping="true"/>
in the <system.web> section of the web.config. I did this and it worked.
We run a link redirection service which can handle links thrown at it in various formats. One of these formats is to append the destination URL to the end of the link, for example
http://url.fwd/abcd/http://www.mydomain.com/page.aspx
This was working on a Windows Server 2003 / IIS6 box for the last two years, but now we're trying to move to a Windows Server 2008 / IIS7 setup and its not working anymore.
I've read about the problem with colons in the URL but it doesn't affect pages not ending in '.aspx'. For instance,
http://url.fwd/abcd/http://www.mydomain.com/page.php
would redirect fine.
http://url.fwd/abcd/http//www.mydomain.com/page.aspx
also works fine (note the lack of a second colon). Despite being the wrong URL, it does get handled by our URL forwarding system, which uses a custom 404 page. On the old system, we had a similar problem, so a method was written in Global.asax > Application_Error specifically to handle the '.aspx' case, and it worked fine.
On our new server, the Application_Error never gets thrown in Global.asax. Instead, I get a System.NotSupportedException - "The given path's format is not supported". This System.NotSupportedException is the exact case we handle in the Global.asax page, so it's definitely not being fired.
I've changed the registry keys indicated in several forum posts,
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET VerificationCompatibility=1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP|Parameters AllowRestrictedChars=1
I've tried changing the Handler Mappings settings for .aspx.
I've tried setting the App pool to use classic mode instead of integrated, but this causes a completely different error where static content such as images and CSS do not display at all. I've checked that static content is enabled in the windows features, and it is.
Under classic mode, the '.aspx' request throws two Bad Request errors with absolutely no information whatsoever. The code of the error page I get is literally
Bad Request<html><body>Bad Request</body></html>
UPDATE: I've changed the static file Handler Mapping to the form found in this page
http://improve.dk/blog/2006/12/11/making-url-rewriting-on-iis7-work-like-iis6
However, as the author rightly points out, this is a hack and not the correct way of doing things under IIS7. It also only fixes the static file problem in classic mode. '.aspx' pages still throw an error under classic mode.
Any thoughts or input would be greatly appreciated at this point.
IIS 7 Solution
The easy solution in IIS 7 is to add a setting in your web.config file to tell IIS to process all requests through your Global.asax events. Just add or change this section in your web.config to enable requests:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
In my case, I was publish my site in production and I miss copy to server App_global.asax.compiled file. For this reason was not fire the Events inside Global.asax.
Hope anyelse help this tips, I lost 8 hours seeking.
What's the difference in using the IIS Redirect module to redirect vs. just coding your own and playing with the Response.context? To me it doesn't make a difference, they both do the same thing and it's much easier to just use the redirect module in IIS as it appears to redirect relatively anyway! Same as this code is doing in lets say a global.asax:
app.Response.Status = "301 Moved Permanently";
app.Response.AddHeader("Location", newLocation);
Am I not right? you can do the same thing 2 different ways! IIS or code! Using IIS just puts this into your app's web.config:
<httpRedirect enabled="false" destination="http://www.domainToRedirectTo.com/" exactDestination="false" httpResponseStatus="Permanent" />
nice and simple! exactDestination is false, so it will redirect relatively based off of the destination.
I want to hear arguments against using one way vs. the other because I don't see an argument that benefits either way. The both satisfy the same goal.
There is no difference in the way you have put it. A coded version allows you to react on input at runtime and use the code to redirect people to different pages --e.g., for a login.aspx page this might be a redirect to login-failed-page.aspx or login-succesfull-page.aspx. If its just hard-coded there is no difference.
Remember that redirects are not just meant to indicate permanent relocation of URL's. 301 is just one of the redirects. You may want to redirect people to a temporary message (redirect code 307) -- e.g., if you are working for apple and Steve Jobs is giving a keynote -- i.e., redirecting the store to a "Steve Jobs is giving a keynote and we are updating the store" page. In this example its far better to flick a switch and have your entire web-farm pick up the change via runtime logic than having to update the config files of all your IIS servers. Each redirect has its own purpose.