Item1475: How to make it work with ActiveState's PerlIs.DLL (MS IIS inprocess engine) (IIS only, not a release blocker)

There are (as far as I know so far) three problems with using Foswiki with IIS and ActiveState's perl and their PerlIS.dll.

1. Tainting : this can be solved by setting the PERL5OPT variable to -T SYSTEMWIDE (this can then be reset per user then). I don't know where to put this in some installation docs. There do not seem to be any for Win+IIS+!ActiveState.

2. NPH : the PerlIS.dll requires that the scripts print the "HTTP/1.x Code Message" before the headers (don't ask me why!). This can be solved by adding

if (defined($ENV{'PerlXS'}) and $ENV{'PerlXS'} eq 'PerlIS') {
   my $status = $this->{headers}->{Status} || "200 OK";
   $hdr = "HTTP/1.0 $status$CRLF" ;
   delete $this->{headers}->{Status};
}

into Foswiki::Response::printHeaders(), just above the foreach.

3. HTTP_COOKIE : for performance reasons (or at least that's what they say) PerlIS doesn't populate ENV completely right away, but instead populates the keys&values if you specifically ask for them. This seems to confuse some module into thinking that the cookie is not set (not sure which yet, it's somewhere outside Foswiki.) The easiest (though a bit hacky) solution is to all this line into setlib.cfg or LocalLib.cfg:

$ENV{HTTP_COOKIE};

I know it's silly and it should be solved more cleanly somewhere else, but this seems to work for now.

Also, I believe the Location: header should contain absolute URLs (including the hostname) for the redirects. Which means something like

  if ($url !~ m{^\w+://}) {
    $url = '/'.$url unless $url =~ m{^/};
    if ($ENV{SERVER_PORT} != 80) {
      $url = "http://$ENV{HTTP_HOST}:$ENV{SERVER_PORT}$url"
    } else {
      $url = "http://$ENV{HTTP_HOST}$url"
    }
  }

should be added into Foswiki::Response::redirect() before the

my @headers = ( -Location => $url );

line.

-- JendaKrynicky

I don't have IIS, nor does anyone else I know in the dev team, so we could apply these changes but would have no way to test them.

So I'm going to raise it to Urgent (for IIS users), mark it as Waiting for Feedback from someone with IIS, who is prepared to check these changes in and document.

As such this is not a release blocker.

-- CrawfordCurrie - 25 Jun 2010

It makes no sense setting waiting for some arbitrary text. Noone has ever reacted to that. But people avoid looking at things that are waiting for.

Why not fix it in collaboration with JendaKrynicky?

We can confirm it does not break Apache, and he can confirm it works with IIS.

This is not a release blocker. Making it a release blocker for IIS makes no sense. We release 1.1 no matter if this is fixed or not. That is obvious. So it is a Normal bug.

-- KennethLavrsen - 18 Jul 2010

yup, though i'll set it to me as once in awhile i actually do run IIS, and do some ASP.NET - mad i know.

-- SvenDowideit - 20 Jul 2010

I know this isn't a release blocker, but could we please get this added in? At least the headers part; I am not sure the modification of the Location: header for redirect matters for my config.

I just spent several hours trying to remember how to fix my config after installing foswiki 1.1.3 over my setup; I finally found my way back to this web page.

Also, the configure script has a problem where IIS is emitting headers before foswiki can get a chance, but I haven't been able to find where to put a similar NPH trap.

-- MatthewKoundakjian - 27 Apr 2011

This "fix" still works in 1.1.4. I need to buy JendaKrynicky a beer or something; and I still can't figure out how to modify the configure script similarly. In IE, configure works adequately but not correctly. In Firefox, I get the page source.

- MatthewKoundakjian - 05 Apr 2012

Nobody is taking ownership of this change. I think the excuse is that only a handful of Foswiki developers are testing with windows at all, even fewer with IIS.

So, I've been trying to improve that situation. My group at work has a Win2008 R2 server that is available for anyone in the Foswiki developer community to use, you just need to contact me. It's actually running Apache + Strawberry perl at the moment but I can easily have IIS + ActiveState installed.

Here's how we can close this task, two options:

• Wait for an existing Foswiki developer to take ownership of the task and commit the code

Or you help us configure an IIS + ActiveState Foswiki installation that we can all test with.

• RequestAccessToSubversion (you)
• Grant access to the TRIN windows build server (me)
• Get IIS + ActiveState installed (me)
• Configure IIS + Foswiki (you & me? This is the important part)
• Commit the above code changes to Foswiki (hopefully you)
• Set up a nightly build which reports any future windows breakages to foswiki-svn (you/me/whoever)

- PaulHarvey - 06 Apr 2012

Paul, that's awesome of you, but I don't know how long it'd take me to come up to speed with the code base and not cause more trouble than I'm worth. Let me do some reading on the processes and responsibilities of making commits and I'll get back to you.

-- MatthewKoundakjian - 10 Apr 2012

Matthew,

don't worry too much about causing trouble - we thrive on it.

More importantly, its much mroe likely that we'll look into the area if someone else fixes an issue and that causes side effects - we are here to help

-- SvenDowideit - 11 Apr 2012

If you were to help us configure a working Foswiki + IIS setup, that would be tremendous start. Briefly documenting the steps as you go.

At least we would have an environment we could test the changes with. But it's then a very small step from there, to committing the code changes yourself You could even commit from the build server, if you wanted.

-- PaulHarvey - 11 Apr 2012 - 01:07