IIS4-Problem

[Thomas Berger]

Cord Veltkamp wrote:
> 
> Herr Loenarz (Loenarz at mnd.fh-wiesbaden.de) schrieb an mich direkt:
> 
> > wir nutzen seit einiger Zeit Ihre gute Allegro-WWW Schnittstelle mit einer
> > Allegro-Datenbank um unsere Diplomarbeiten im INternet zu veröffentlichen.
> > Wir nutzen Windows NT 4.0 Server mit dem IIS 3.0
> > Leider mußten wir nun auf den IIS 4.0 umsteigen, was natürlich zu Problemen
> > führte. Ihren Hinweis bei 3.0 in der Registry aktiv zu werden hat uns sehr
> > geholfen.
> > Haben Sie Erfahrung mit dem IIS 4.0 - oder was raten Sie uns ?
> 
> Tut mir leid. Wir haben hier keine Erfahrungen mit IIS 4.0 und mir fehlt jetzt
> auch die Zeit, mich mit diesem Problem zu befassen. Aber vielleicht kann ein
> versierter NT-Anwender unter den allegro-Experten Ihnen helfen. Das Problem
> ist sicher von breitem Interesse.
> Meine spontane Idee (ohne das Problem zu kennen) waere, die fuer den IIS 3
> noetigen AEnderungen wieder rueckgaengig zu machen.
> 
> Es gibt vermutlich ein Problem zwischen IIS4 und Perl. Sie koennten unter den
> FAQ's zu Perl und IIS suchen. Auch dort gibt es Mail-Listen.
> Als letzte Moeglichkeit bleibt immer noch den Umstieg auf einen weniger
> kritischen Server, z.B. XITAMI (->allegro-CD ).

Leider wird das Problem nicht so recht klar.
Nach meinen Erfahrungen ist der IIS 4.0 auch nicht problematischer
oder spezieller als andere Webserver.

Typische Problemstellen sind, der Reihenfolge nach:

- Falls der Server unter NT als Service
  laueft, ist es ein anderer User als der
  Administrator. Hier muessen die Zugriffsrechte
  auf den realen Verzeichnissen stimmen.

- Ist das virtuelle Verzeichnis fuer das
  Ausfuehren von Scripte konfiguriert?
  (das hat NICHTS mit den Rechten auf den
  Realen Verzeichnissen zu tun).

- Wird Perl vom Webserver gefunden?
  * XITAMI z.B. erwartet es im Suchpfad
  * die Microsoft-Familie in der Registry 
    (Online-Hilfe des Servers lesen: "ScriptMap"!)
!   Es ist aber immer (?) ein Schluessel in 
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3Svc\Parameters\Scriptmap
    dort ist ein Zeichenfolgenschluesselpaar
    .pl -> "c:\perl\bin\perl %s %s"
    einzutragen (oder wo auch immer Perl ist)
  * bei anderen kann man es direkt konfigurieren

- Wird das Perlskript im richtigen Verzeichis
  gestartet?
  Das ist bei allen Servern eigentlich das Verzeichnis,
  wo das Skript liegt, ausser bei XITAMI, wo man dieses
  Verhalten erst als Option ankreuzen muss.
  Fuer acwww25 sollte dies aber egal sein, weil hier
  die Verzeichnisse beim Start explizit gewechselt werden,
  wenn ich mich recht entsinne.



- Alle Server verhalten sich unterschiedlich, wenn
  vor der Ausgabe der http-Header durch das CGI-Programm
  Warnings ausgegeben werden. Dies kann zu Fehlermeldungen
  Dies kann man beeinflussen durch:
  * sauberere Programmierung (vorzugsweise)
  * Einstellen des sog. CGI-Debug-Modus bei manchen
    Servern
  * Entfernen des "-w"-Schalters in der ersten
    Zeile des CGI-Skripts (deprecated).
  Tip: Die Scripten von der Kommandozeile aus zu
  testen spart sehr viel Aerger. Leider geht das
  mit acwww25 nicht auf Anhieb. Ich empfehle daher
  (nicht getestet) folgende Modifikation in der
  cgi-lib.pl  In der Prozedur ReadParse (direkt
  am Anfang), und zwar hinter den Zeilen
# Read in text
if ($ENV{'REQUEST_METHOD'} eq "GET") {
  $in = $ENV{'QUERY_STRING'};
} elsif ($ENV{'REQUEST_METHOD'} eq "POST") {
  for ($i = 0; $i < $ENV{'CONTENT_LENGTH'}; $i++) {
    $in .= getc;
  }
}
  ergaenzen Sie bitte die folgenden Zeilen:
else {   # interaktive Parameterabfrage an Kommandozeile...
  @myin = <STDIN>;
  $in = join ("&", @myin);
  $in =~ s/\s+$//;
  $in =~ s/\s+\&/\&/;
  $in =~ s/\s/\+/g;
}

  Nach dieser Aenderung kann man aus dem CGI-Verzeichnis
  das gewuenschte Script per Hand aufstarten und dann
  zeilenweise Paare von Werten eingeben:
index=PER
s1=tucholsky
...
  Abschluss dann mit <Strg>-Z


HTH
Thomas Berger