Ship Drupal 7 with a configuration file for IIS 7

Microsoft pushing for something should be enough reason to won't fix this.

+1, for several reasons, as it makes drupal more widdespread, and opens up a whole new slew of drupal sites, which are currenly having a vendor lock-in, and makes moving hosts a lot easier when they go over to a LAMP host finally, as we can offer them a robust upgrade path.

about your Preemptive: we should, if they manage to obtain a marketshare of 10% (when will drupal be running on google servers?)

- http://en.wikipedia.org/wiki/Web_server
- http://survey.netcraft.com/Reports/200901/

I would be in favor of this. This gives a better out of the box Drupal experience on more web servers then just Apache.

After the massive amount of issues around clean URL's and the private file system, I have to agree, there seems to be no clear cut, simple way to make these things work on an IIS shared hosting platform, it would be great to have an easy way to do all of this, and for Drupal to just work with IIS7.

Windows is running 30% of all websites? ... I'm depressed now. I'm very, very depressed.

I think this is a good idea. Granted IIS is not open source, but we are trying to make Drupal more accessible not take a radical hard line FOSS stance.

Sure I would love to see MS have less market share in serving web pages (and IE take a nosedive) but we should remain focused on spreading Drupal and making it the CMS of choice. Let's not cut off our nose to spite our face.

+1

Another reasoning is that IIS, being very easy to install, will be installed a lot by people who are less informed when it comes to security. In other words: someone who manages to get a custom lighty running, has a bigger chance of being security aware, then a user clicking on three [next »] buttons.

We -as Drupal- should avoid opening vulnarabilities on those people's machines. It will backfire: if word gets out that 'installing Drupal on IIS opens security holes', even if it technically is the users fault, we get the blame.
If avoiding that, is as simple as adding a simple file, I see only reasons to include that file.

Downside is that is will need to be maintained, to avoid giving people a false sense of security.

Another reasoning is that IIS, being very easy to install, will be installed a lot by people who are less informed when it comes to security.

I don't agree with that at all. On Ubuntu just type sudo tasksel install lamp-server and you're done. And IIS 7 is pretty rock solid secure from the beginning.

Obscurity doesn't mean security, and ease of use doesn't mean insecure.

Seems like an obvious win. Just needs a reviewer to move it to rtbc.

I think I'd be fine with this, too. The only real reason not to do it is the "slippery slope" argument, but when we're talking about this type of critical security (not to mention usability) enhancement, I'm not sure that holds much weight.

IIS 7 out of the box is pretty darn secure. I have successfully unsecured Apache based setups faster then IIS based setups because of familiarity based causes.

I'm running with that for a few weeks now. Works flawlessly out of the box.

Ok, let's do this then.

Committed to HEAD.

Same works for Drupal 6 (given this was adapted from Acquia Drupal)?

--- /dev/null
+++ web.config

Shouldn't we hide this file from prying eyes?

Powered by Dreditor.

@sun: there is no real need to. We don't hide CHANGELOG.txt, I don't see why we should hide web.config. On Windows systems, this file is automatically hidden by IIS.

We need automated tests for this: #771430: Add test bot running IIS + Windows

The “Protect files and directories from prying eyes” rule differs from that in .htaccess. It omits .make files and adds .svn-base files. I assume this wasn't intentional?

Also, the file does not implement the protection added in #581706: Protect .git, .hg and .bzr directories in .htaccess. Is that possible simple by extending the pattern in the <match url=""> rule?

This patch has not been tested.

+++ web.config	15 Apr 2010 20:50:29 -0000
@@ -1,43 +1,43 @@
-          <match url="\.(engine|inc|info|install|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl|svn-base)$|^(\..*|Entries.*|Repository|Root|Tag|Template)$" />
+          <match url="\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)$|^(\..*|Entries.*|Repository|Root|Tag|Template)$" />

Am I blind or is .config not added here?

Also, what about .config in .htaccess?

Powered by Dreditor.

This .config is irrelevant except on IIS, and on IIS it is unbrowseable unless the IIS administrator changed that parameter. That would be a really weird change.

This patch has not been tested.

Let IIS users test? I can't see what could break with this patch.

Committed to CVS HEAD.

Same works for Drupal 6 (given this was adapted from Acquia Drupal)?

Do we need to bump that to D7 again?

Yes, looks like.

CVS version patched and installed with minimal version on Windows2008 without any problems

I'm not a IIS user but this looks reasonable for inclusion in 8.x. Committed. Requires more review before this can be committed to 7.x.

Tagging, so I don't lose track of this.

i used 2 last patches on drupal 7 web.config

i have not clean url if patch this section

-          <action type="Rewrite" url="index.php?q={R:1}" appendQueryString="true" />
+          <!-- Pass all requests not referring directly to files in the filesystem to
+           index.php. Clean URLs are handled in drupal_environment_initialize(). -->
+          <action type="Rewrite" url="index.php" />

Windows web server 2008 R2 iis

Marked #1537898: Fix for web.config for windows based installs as duplicate, since it proposes the same change as this part of the patch:

     <defaultDocument>
-      <!-- Set the default document -->
+     <!-- Set the default document -->
       <files>
-        <remove value="index.php" />
+         <clear />
         <add value="index.php" />
       </files>
     </defaultDocument>

I'm running with that for a few weeks now. Works flawlessly out of the box.

It would be helpful if the web.config file contained a brief comment to explain what the file is for.

I found out through the file's git history, and I suppose a quick internet search would answer the question, but a brief comment would be harmless and useful.

Patch attached (rolled against 8.x-dev)

D8: #1914932: Config staging directory needs a .htaccess file

#41: do567072-web.config-explain_file.patch queued for re-testing.

41: do567072-web.config-explain_file.patch queued for re-testing.