I've inherited an old system after starting a new job, none of the previous developers work here any more and none of them documented all that much. Fun times.
The system uses an old, defunct CMS and I've just finished a large ordeal whereby I could not for the life of me figure out how routing worked (the client wanted a URL changing). It later turned out that the previous developers had been using a completely separate program called "Helicon ISAPI rewrite" and had been doing all of the site's URL management from there.
My question is: How could I have figured this out more quickly (e.g. are there external tools I could have used or logs I don't know about that would have revealed how this routing was working)?
I spent a whole afternoon picking through 10 years worth of code when the answer wasn't even in there! Right now I'm feeling that I had no chance of figuring that out quickly but I'm wondering if I'm missing something.
I think I understand what you're asking, to discover the rewriting in the first place. Tony's answer is right if you knew about ISAPI_Rewrite up front, but hindsight is 20-20. I'm a big fan of ISAPI_Rewrite and Helicon Ape, so I might have suspected it. However, if the rewriting was being done by IIS7's .NET web.config, I wouldn't have looked there (although I guess web.config should be a place to start for anything IIS-screwy). With a legacy CMS or something like WordPress, I wouldn't know where to start, so I would probably start with the code like you did.
I suppose the real starting point is the top of IIS, before the request even gets to the web code.
Looking around in IIS7, I see Handler Mappings, with a whole bunch of stuff in there, intercepting various requests. These could all "do things" to the request before it hits the website. e.g., I see Microsoft's ExtensionlessUrlHandler... which gave us troubles as a breaking changing when upgrading to .NET 4.0. We had to dig around for this, wondering what was putting eurl.axd into our urls.
IIS6 has an ISAPI Filters tab on the website properties. Mine has ISAPI_Rewrite and ASP.NET_2.0.... in it. There's also an HTTP Headers tabl with MIME types, that can be a culprit for diverting requests.
Knowing this now, perhaps a list of all rewriting software would be handy. Just search the system for any of them installed - might be the fastest way to a get the first clue.
And actually, if you spent an afternoon in 10 years of code, that's not too bad! So you may not have had a chance of figuring this out quickly - any legacy system is going to have buried secrets.
If it's ISAPI_Rewrite v3, you can enable logging in httpd.conf in ISAPI_Rewrite installation folder by putting the following lines:
RewriteLogLevel 9
LogLevel debug
Then after you make some test request, the rewrite.log and error.log file will appear in ISAPI_Rewrite installation folder. error.log shows general issues, while rewrite.log shows how and if the rules are applied and what the resulting URL is.
Related
I have been using Helicon to rewrite my URLs and they are in a file htaccess (no dot). The rewrite goes something like:
RewriteRule /e-commerce /e-commerce.asp [I,U]
I have read a few answers, starting with How to Determine the Installed ASP.NET Version of Host from a Web Page. I ran the page, and it displayed 2.0.50727.3643
A little history so maybe one can be gentle. I was a Microsoft Frontpage MVP, but disliked their Frontpage Server Extensions (FPSE). Some hosting companies are still using them, but the last ones were back in 2002.
I was a Microsoft guy. So I went with Microsoft servers and started using ASP includes. Then I came across Helicon - and used it for 4-5 yrs. Some of my sites are having no issues, but some of them are. And my new prices along with new hardware for credit card processing is out and I really need help (BTW, I looked for an e-commerce section but found nothing if y'all have one, I'll be more than happy to help).
I do not even know what is the file name I should be using and the information that goes in there.
Rename a file in C#
How to rename a file in .NET?
Rewriting URLs in ASP.NET/C#
Custom Url Rewriting in asp.net
I have seen several file names but I do not know which one to use. I am sure there is a question out there that matches mine, but after looking for several hours, I am hoping some of the experts will be able to help me out.
Thank you!
You should give a try to URLRewriter.Net. It's very easy to integrate into asp.net project. Instead of IIS level it implements url rewriting at asp.net level.
Usually when I get the url of a request i use Request.RawUrl.
This gives /default.aspx for example.
However recently my host changed something and now the name of the application directory is displayed as well so i get /appdirname/default.aspx.
Now why does it give me the directory of the application? It looks as if my website is a subapplication of another website. So when you go to mydomain.com the rawurl will be:
/appdirname/default.aspx
I believe each domain has it's own website defined in iis or am i mistaken.
I am not asking for a workaround, which should be pretty straightforward, I am asking why this is happening and how, what kind of IIS setup causes this to happen?
PS.
And the worst part is i had this issue with godaddy and i was happy my host didnt have it but now both hosts have the same problem.
The Request.RawUrl method returns everything after the domain declaration, so if your full url is:
http://www.yourdomain.com:8080/directory/Page.aspx
then the method will return
/directory/Page.aspx
That's all it does. That's all it claims to do. As you say, your hosting provider must have changed something, which is very naughty, and the workaround should be easy. There is a good chance that they have introduced some kind of url redirection, but the best way to find out is to get in touch with their helpdesk and ask them what is happening. I find that most successful hosting companies tend to respond in good time to this kind of question. Otherwise they tend to become formerly-successful hosting companies.
Ric Strahl has this to say about it: http://www.west-wind.com/weblog/posts/132081.aspx
In my research, I found 2 ways to do them.
Both required modifications to the Application_BeginRequest procedure in the Global.Asax, where you would run your code to do the actual URL mapping (mine was with a database view that contained all the friendly URLs and their mapped 'real' URLs). Now the trick is to get your requests run through the .NET engine without an aspx extension. The 2 ways I found are:
Run everything through the .NET engine with a wildcard application extension mapping.
Create a custom aspx error page and tell IIS to send 404's to it.
Now here's my question:
Is there any reason one of these are better to do than the other?
When playing around on my dev server, the first thing I noticed about #1 was it botched frontpage extensions, not a huge deal but that's how I'm used to connecting to my sites. Another issue I have with #1 is that even though my hosting company is lenient with me (as I'm their biggest client) and will consider doing things such as this, they are wary of any security risks it might present.
`#2 works great, but I just have this feeling it's not as efficient as #1. Am I just being delusional?
Thanks
I've used #2 in the past too.
It's more efficient because unlike the wildcard mapping, the ASP.NET engine doesn't need to 'process' requests for all the additional resources like image files, static HTML, CSS, Javascript etc.
Alternatively if you don't mind .aspx extension in your URL's you could use: http://myweb/app/idx.aspx/products/1 - that works fine.
Having said that, the real solution is using IIS 7, where the ASP.NET runtime is a fully fledged part of the IIS HTTP module stack.
If you have the latest version of IIS there is rewrite module for it - see here. If not there are free third party binaries you can use with older IIS (i.e. version 6) - I have used one that reads the rewrite rules from an .ini file and supports regular expression but I cant remember its name sorry (its possibly this). I'd recommend this over cheaping it out with the 404 page.
You have to map all requests through the ASP.NET engine. The way IIS processes requests is by the file extension. By default it only processes the .aspx, .ashx, etc extensions that are meant to only be processed by ASP.NET. The reason is it adds overhead to the processing of the request.
I wrote how to do it with IIS 6 a while back, http://professionalaspnet.com/archive/2007/07/27/Configure-IIS-for-Wildcard-Extensions-in-ASP.NET.aspx.
You are right in doing your mapping from the database. RegEx rewriting, like is used out of the box in MVC. This is because it more or less forces you to put the primary key in the URL and does not have a good way to map characters that are not allowed in URLs, like '.
Did you checked the ASP .Net MVC Framework? Using that framework all your URLs are automatically mapped to Controllers which could perform any desired action (including redirecting to other URLs or controllers). You could also set custom routes with custom parameters. If you don't have seen it yet, maybe it will worth the look.
Please see my DNN Forum Post for more details.
I've never had any issues with DotNetNuke installations. But with the new v5.20 (or v5.02, whichever it really is), everything runs perfectly fine through installation. I then get to the main default portal homepage. But as soon as I click any of the links available to continue (Home, Register or Login) I get 404 errors every time with a reference back to the applicable aspx page (Home.aspx, Register.aspx or Login.aspx.).
Windows 7, IIS7, SQL Server 2008. All permissions are setup properly on the directory and in IIS. I would think this is an IIS7 configuration issue, but I've tweaked everything in there a half-dozen times. No one at DNN is returning answers on my forum post anymore either after one guy tried.
Help!
This is something to do with the Friendly URL stuff. I found this blog post which talks about the Friendly URL Provider architecture. This made me try changing the urlFormat attribute for the DNNFriendlyUrl provider from "humanfriendly" to "searchfriendly", which made the URLs the way they used to be. I'm not sure exactly where things are going wrong and don't really have time to dig into it at the moment, but hopefully this will be helpful to get you moving again too.
With the release of DNN5 (up until 5.02.01 as of the time of writing), the friendly URL provider won't work when DotNetNuke is not on default port 80. There are different solutions floating around, but the simplest is just to replace the DNN friendly URL provider with the free one from iFinity. The installation is really simple and included in the download. Or see the following blog post:
http://www.sailer.com.au/dotnetnuke/dnn5-friendlyurl-port
Okay have you tried the 'old style' of login - domain.com/default.aspx?ctl=login
If that still doesnt work then i have to say that most likely something has happened to IIS - if so then you might just see if you can install the package you have on a different box or have a friend try a different box
I have done 2 upgrades with 5.2 and a few test installs with the Starter Kit Package and Install packages and have never seen this problem - not to say that it doesnt exist.
My next trial would be to go and redownload the install package from CodePlex and start from scratch to see if you can make the same thing happen again.
OKayone thing I dont think that has been mentioned in reading through everything is double check IIS.
My first guess without looking on your server would be to check if something happened to the 'check file exists' setting - i know this is changed in IIS7 so I cant point to the exact place to check this.
Here is a link to the IIS7 forums on it - http://forums.iis.net/t/1092696.aspx
http://forums.asp.net/t/1191083.aspx
either one might help - google also has a lot on this
Tell me how this goes in checking up on it and we can move forward from there!
you probably need to reg_iis on the version(s) of asp.net that your IIS is going to support.
http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
If the right version is not set up then you will get the 404 error
So placing it under port 80 works, right?
Is there a good reason not putting it under that port?
A customer is asking if there is anything we can do to remove "/Pages" from his Internet-facing MOSS publishing site. Some Googling reveals that some clever use of HTTPModules may be able to hide the presence of Pages, but I've yet to see an end-to-end working solution. Have any of you come up against this particular requirement, and if so, how did you resolve it?
The customer's main concern with /Pages is the SEO impact of it - if anyone has any way to mitigate those issues or can explain why having this extra level in your URL would not be a concern, that would be appreciated as well (and probably better, in the long run!)
Check out this posting. http://blog.mastykarz.nl/semantic-urls-in-moss-2007-imtech-sharepoint-semantic-urls-free-feature/
The main issue you'll have is that Microsoft won't provide support for a SharePoint instance that has "hidden" the pages library.
Yes, you can use a URL re-writer to exclude the /pages section of the path, and you will also need to perform a search and replace on the response stream to strip it out of all generated URLS - this will obviously have a performance hit on the server - but with careful use of caching, it might not be that noticable.
PSS will require you to remove the setup before they will investigate any issues with your site, so you (or your client) will need to weigh up the perceived benefits with the performance and support issues.
I believe we've done it for one of our clients in the past, but most are happy to stick with the /pages element - it really doesn't have that much effect.
I know ASP.NET 3.5 SP1 has the URL routing engine that ASP.NET MVC uses built in. If you wanted to run against that version of the .NET framework, you could use routes to eliminate the /Pages part of the URL. But I'm not positive about running MOSS on that version of .NET. That's the first place I'd check, though.
You can get a list of public facing websites using MOSS here. You can see they use the "page" libraries and you can check your favorite search engines against the content.
Hopefully this will be enough to demonstrate that the "Page" libraries aren't going to be too much of an issue and you can save them a bunch of cash.
You can change the name (and the url) of the /Pages library.