> Message: 5
> To: moin-devel@...
> From: Alexander Schremmer <2004b@...>
> Date: Mon, 24 Jan 2005 21:44:44 +0100
> Organization: XOR AX,AX
> Subject: [Moin-devel] Re: 1.3.2 does not run on IIS due to
> error in request.py
> On Mon, 24 Jan 2005 17:24:42 +0100, Alexander Schremmer wrote:
> >> In request.py, function
> RequestBase::_setup_vars_from_std_env there is some
> >> special code to handle some strange stuff on windows.
> Yeah, it is even new in 1.3.2.
> >> The first branch is supposed to be checking for apache and
> if this fails,
> >> the second branch is checking for IIS.
> The first branch is just used if the server supplies
> request_uri. IIS does
> not, so it will be relevant if the CGI is just executed on IIS.
> If the first branch was not used, the second checks if IIS
> called the CGI
> script. If this is true, it tries to decode the path_info.
> >> However the second branch is never executed due to an
> obvious error in the
> >> first check:
> I still do not think that this is an error.
Sorry, I forgot to mention that I had fixed the request_uri issue as well.
IIS does indeed not supply 'REQUEST_URI', so my workaround for an issue with
this (I think I fixed this in 1.3.0 already and did not think about it) was
self.request_uri = env.get('REQUEST_URI', '%s'%self.script_name)
(this is probably not quite correct, I just needed something useful in that
variable for the request.url variable that is used to find a wiki in a farm
Thus, the first check was always true in my case and the problem was
self-made. Nevertheless I think that
server_software.find('Apache/1.3') == -1
was meant to be
server_software.find('Apache/1.3') != -1
if the first check was intended for apache only.
In any case, changing this fixed my problem just fine. The second check was
executed and did its magic.
However, as there are some places that use self.request_uri there should be
a safe setting of this variable other than '' even in the case that the
server does not deliver 'REQUEST_URI'. My fix is probably not the best way
to do so.
Unfortunately my wiki farm (with a total of 4 wikis, a lot of patches and
special development including forms-based database access, currently
migrating from 1.1 on IIS 5 to 1.3 on IIS 6) runs on our intranet and I
can't supply an external url (which means I have to solve all the riddles by
> >> The symptoms of this error were not easy to understand,
> because most of the
> >> unit tests (I re-enabled them) worked OK and I could
> perfectly work with
> >> FrontPage - but only with FrontPage! Whichever page was
> requested I always
> >> got just FrontPage.
> Funnily, this should be the consequence after applying your hints :-)
> I have installed IIS just because I wanted to make sure that
> my addition in
> request.py was correct. Besides a minor error that disallowes
> the page view
> of pages containing characters that cannot be displayed in
> the system code
> page (e.g. Asian ones), it was perfectly valid and worked without any
> further problems on IIS 5.1.
> A little fix for that glitch will be in the hotfix release that
> ThomasWaldmann will finish in the next hours.
> Maybe you should check in your configuration if you enabled
> "Check that
> file exists". This may not be enabled because IIS would check if the
> (virtual) page name exists in the directory script.
> If this still does not fix your problem, you should try to contact my
> Kind regards,
> Moin-devel mailing list
> End of Moin-devel Digest