I'm working on (surprise) a web framework that entirely is dependent on mod_rewrite, however I'd like for it to be compatible with IIS ( if possible ). There's a slight slight chance one of the sites being built will have to be stored on an IIS box, I'm wondering if there's any rewrite module in the most popular versions of IIS I could rely on.
IIS7 is easy--use the URL rewrite module as Garethm points out.
IIS<7 is a bit trickier--no integrated pipeline to latch on to. Presuming you can require that persons hosting on IIS have dedicated hosting, or can at least get an ISAPI module installed, check out iconic's Isapi Rewrite Filter. It is free, open source and pretty much mimic's mod-rewrite.
For IIS7, there is the IIS URL Rewrite Module. If I remember correctly, you can install it with the Web Platform Installer.
There also appears to be a company that has rewritten a rewriting module for IIS that is compatible with Apache's mod_rewrite configuration format. You can find out about it on the Micronovea website. I have no experience with this one though.
I've used HeliconTech's ISAPI_Rewite with great success. It's not free or open source but it's reasonably cheap and well supported, also super-easy to install and get running.
Helicon also have a 'lite' version that is free.
Related
I have a legacy ISAPI dll, that generally fulfills requests just fine, but occasionally I will get prompted to save the dll from my browser. This is a known issue, with some good workarounds. IIS 8.5 serving dll for download instead of executing Hitting download will give you a zero byte file.
I am actually interested in doing the opposite of the workaround. How can I force this (incorrect) behavior, ie, is it possible to trick the server to download the full ISAPI dll? If so, what settings should I change. I am running IIS 7.5.
[EDIT] For clarity, I am not trying to hack anything client side. I doubt that's possible, but if it is I would really like to know. I am trying to figure out if it is possible to get the server to give up the dll with just a plain old post/get request. This is how I got it to give me the dll the first time, luckily it was zero bytes.
Thank you
I tested the TYPO3 extension secure_downloads on development site, and it worked fine. When I installed it with identical settings on the production server, which uses HTTPS, it failed to generate the secure links.
This is under TYPO3 6.2 LTS, and version 2.0.3 of the extension.
I thought that the extension https_enforcer might be an issue, but the problem persists after removing that.
Thank you.
In the extension configuration, you can force the HTTPS by configuring
Parsing | Domain [basic.domain]
to the full https://example.com/
While that setting is supposedly "not needed for internal (relative) links," it is needed if you want to always use a secure connection.
I am using Application Request Routing 3.0 with IIS's failed request tracing. I am having issues with my rewrite rules so I wanted to troubleshoot it.
I wanted to follow the steps below to enable IIS logging of rewrite rules but the option doesn't seem to be there for me.
http://www.iis.net/learn/extensions/url-rewrite-module/using-failed-request-tracing-to-trace-rewrite-rules
I am using Windows 2012 R2
If the Failed Request Tracing was installed after URL rewrite module,
the "Rewrite" area in Trace Providers may not be available. If you do
not see "Rewrite" area listed there, go to Add/Remove programs and
then run URL rewrite module installer in repair mode.
Original source
TLDR: you can also just reorder the FRT module to be listed BEFORE the urlrewrite module in IIS.
This simpler solution may appeal to some, versus that ms-documented suggestion to just reinstall urlrewrite. You can go to the server level in iis, choose the "modules" feature, and use its "view ordered list" option. There you will see (in this scenario above) that the Failed request trace module is listed AFTER the urlrewrite module--reflecting the fact that FRT was enabled AFTER urlrewrite was installed. It's an easy situation to end up in, and many then never realize how much frt can help with tracking rewrite rules.
But rather than reinstall urlrewrite (the stock answer), you can just move the frt module to be before urlrewrite, using the options offered there to move modules up or down. (The steps to do that are well-documented by MS and others, so I'll not elaborate them here.)
This way, the frt feature is loaded first and this can watch/track rewrite processing--again achieving the same goal as the proposed uninstall/reinstall of urlrewrite.
Hope that helps some. Sadly, even a lot of resources on using FRT to help debug rewrite rules don't acknowledge this surprisingly common problem, let alone either solution here.
I've added the following XML to my SiteUrls.config file:
<RewriterRule>
<SendTo>/pod/</SendTo>
<LookFor>.*abcdefg</LookFor>
</RewriterRule>
When I go to http://localhost/abcdefg it successfully redirects me to http://localhost/pod. My localhost is an IIS 7 web server.
However, I am unable to get this same exact configuration to work on our production or staging machines. It stays on http://staging.x.com/abcdefg and gives a 404 error.
What exactly needs to be set up to allow this to work? I have not noticed much difference between the IIS modules I have locally and the IIS modules on the production/staging systems.
You may need to install a hotfix to support extensionless URLs on IIS 7.
From Hanselman:
Getting extensionless URLs working on IIS6 was tricky before and lots of been written on it. Early on in IIS6 and ASP.NET MVC you'd map everything . to managed code. ASP.NET Routing used to require RAMFARR set to true until the Extensionless URL feature was created.
Extentionless URLs support was added in this KB http://support.microsoft.com/kb/980368 and ships with ASP.NET MVC 4. If you have ASP.NET MVC 4, you have Extentionless URLs on your development machine. But your server may not. You may need to install this hotfix, or turn on RAMMFAR. I would rather you install the update than turn on RAMMFAR if you can avoid it. The Run All Modules options is really a wildcard mapping.
I have a problem with IIS 6.0 ceasing to work for an ASP.NET application after installing Service Pack 1 for .NET 3.5.
I have 2 identical virtual dedicated servers. Installing SP1 on the first had no adverse effect. Installing it on the second caused ASP.NET pages to start returning 404 page not found.
Static .html pages working okay on both servers.
Has anybody else experienced this?
This is broad problem, so let's start by asking some troubleshooting questions:
Based on your description, the ASP.NET runtime is not catching your request and processing the aspx files. You may need to register the asp.net pipeline with IIS again using ASPNET_REGIIS -i.
Have you made sure that the app_offline.htm file has been removed
from the directory of the application?
I have had this happen before after an
update.
Have you setup fiddler for instance to follow the request to see what is
exactly being requested?
Make sure ASP.NET is enabled in the IIS Administration Console under "Web
Service Extensions." Make sure everything is set to allowed for your different versions of the framework.
Well, let's start with those and hopefully we can guide you to the problem.
I've seen various people with this problem recently. This link might help.
And this one.
And a few others.
Is CustomErrors in your web.config set to On or RemoteOnly? If so, what do you get when you change it to Off?
I have not had this exact error with .NET 3.5 SP1, but have seen similar occur in the past. Typically it can be resolved by opening a command prompt, going to the appropriate .NET folder and running ASPNET_REGIIS -i. In the case of .NET 3.5 there wasn't an update to the main bits of the framework, so you'd actually go to the .NET 2.0 folder, which on my machine can be found at:
\Windows\Microsoft.Net\framework\v2.0.50727
Running the ASPNET_REGIIS -i will re-register all the ASP.NET libraries with IIS, and should be the equivalent of a re-install of the framework on a given machine (as far as IIS is concerned)
Just to clarify. The last (4th) point given by Dale was the problem. During the installation of SP1 the Status for ASP.NET and WebDAV became set to Prohibited under Web Service Extensions.
Why the installation of SP1 changed this setting on one server and not the other is a mystery that I wouldn't mind (but not expect) an answer to...
The second link provided by CodingTheWheel also had the answer so I'm also going to mark this as an answer.
No-one did before, so I'll point to the trivial solution:
Have you already de-installed the Service Pack and re-installed it again (or the whole framework)?
Edit: #Kev:
Easy explanation: He said the update works on one machine, but not on the other. I had similar problems in the past and re-installing helped to solve some of them. And it is trivial to do.
That's my approach:
1. trivial
2. easy
3. headache
You are right, on productive systems you must be careful, but that's his decision. And because it is a virtual server, maybe it is easy for him to copy it and try as a test environment first.