Mit Indy (TIdFTP) Script hochladen klappt nicht

[BlueStarHH]

Hallo,

ich möchte mit Indy (TIdFTP) ein Perl-CGI-Script auf meinem Webserver hochladen. Das klappt auch. Die Datei ist da, nur wenn ich sie über den Browser aufrufe erscheint die Meldung "Premature end of script headers". Wenn ich das Perl-CGI-Script mit einem FTP-Programm hochlade, wird sie einwandfrei ausgefürt. Was macht das FTP-Programm anders als Indy?

Delphi-Quellcode:

IdFTP1.Connect;
IdFTP1.TransferType := ftASCII;
IdFTP1.Put(FileName, '\cgi-bin\meinscript.cgi');
IdFTP1.Disconnect;

[DeddyH]

Und wenn Du die Datei einmal binär überträgst?

[BlueStarHH]

Zitat:

Zitat von DeddyH (Beitrag 1106320)

Und wenn Du die Datei einmal binär überträgst?

Komisch, es geht nur wenn ich es wie folgt mache:

Delphi-Quellcode:

IdFTP1.Connect;
IdFTP1.TransferType := ftASCII;
IdFTP1.TransferType := ftBinary;
IdFTP1.Put(FileName, '\cgi-bin\meinscript.cgi');
IdFTP1.Disconnect;

Bei der ersten Zuweisung von TransferType wird Code im Setter noch nicht ausgeführt. Erst in der zweiten Zuweisung. Denn wenn man IdFTP1.TransferType := ftASCII; weglässt, kann das Script nicht ausgeführt werden.

Was noch komischer ist: Überall steht, dass man Perl-CGI-Scripte als ASCII übertragen soll, da sonst die Zeilenübrüche defekt sind und das Script nicht ausgeführt werden kann. Hier muss ich es aber als binär übertragen, damit es läuft. Hat jemand Vermutungen was hier los ist?

[blackfin]

Deine Script-CGI-Datei ist aber nicht zufälligerweise Unicode? :-)

[alfold]

Zitat:

Zitat von BlueStarHH (Beitrag 1106316)

....
Wenn ich das Perl-CGI-Script mit einem FTP-Programm hochlade, wird sie einwandfrei ausgefürt. Was macht das FTP-Programm anders als Indy?

Die meisten FTP Progs (Putti, Winscp)schieben die Dateien Binär hoch!
Es sei, man stellt es anders ein:wink:

Zitat:

Zitat von blackfin (Beitrag 1106339)

Deine Script-CGI-Datei ist aber nicht zufälligerweise Unicode? :-)

Wie sollte es. Wenn er es mit anderen Progs hoch schiebt und es funct:wink:

Gruss alfold

[blackfin]

Zitat:

Wie sollte es. Wenn er es mit anderen Progs hoch schiebt und es funct

Naja, der Server kann ja vielleicht, bzw. ziemlich sicher Unicode-Perl-Scripte ausführen.
Allerdings, wenn man eine Unicode-codierte Datei mit Ascii-Encoding hochschiebt, kann das durchaus die Datei zerstören.
Andere Clients erkennen u.U. trotz eingestelltem ASCII-Transfer, dass eine Datei Unicode ist und schieben sie dann binär hoch (SmartFTP macht das z.B.)
Und das ist auch richtig, Unicode-Dateien sollte man nicht mit ASCII-Transfer hochladen, das gibt Verwurschtelungen.

[BlueStarHH]

Zitat:

Zitat von blackfin (Beitrag 1106339)

Deine Script-CGI-Datei ist aber nicht zufälligerweise Unicode? :-)

Nein, kein Unicode. Lädt Indy die Datei intern evtl. als Unicode und überträgt die dann? Mit einer alten nicht Unicode Version von Indy gab es nämlich keine Probleme...

[blackfin]

Kann gut sein...wenn man sich den Quellcode von der idFTP ansieht, sind da ein paar merkwürdige Sachen mit dem Encoding...
Schickst du an den Server vorher ein "FEAT"-Command?
Da scheint Indy dann das Default Encoding für den String-I/O-Handler auf UTF8 zu stellen:

Delphi-Quellcode:

IOHandler.DefStringEncoding := enUTF8;

hm...
Versuche doch mal, die Datei nicht über die Angabe eines Dateinamens im put-Befehl hochzuschieben, sondern mach die Datei vorher über einen TFileStream auf und übergib den an put.

[BlueStarHH]

Ich hab den Fehler in der IdFTP.pas gefunden:

Delphi-Quellcode:

procedure TIdFTP.SetTransferType(AValue: TIdFTPTransferType);
begin
  if AValue <> FTransferType then begin
    FTransferType := AValue; //von unten nach hier verschoeben
    if not Assigned(FDataChannel) then begin
      if Connected then begin
        SendTransferType;
      end;
      //FTransferType := AValue; //muss nach oben
    end;
  end;
end;

Wenn die markierte Zeile nicht verschoben wird, setzt SendTransferType immer den vorherigen FTransferType und nicht den aktuellen.

[CCRDude]

Verwendest Du eine ältere Version von Indy?

Bei mir (mit DXE mitgeliefertes Indy 10) steht nämlich schon:

Code:

procedure TIdFTP.SetTransferType(AValue: TIdFTPTransferType);
begin
  if AValue <> FTransferType then begin
    if not Assigned(FDataChannel) then begin
      if Connected then begin
        SendTransferType(AValue);
      end;
      FTransferType := AValue;
    end;
  end;
end;

[DeddyH]

Ja eben, er meint ja, dass das Setzen des Wertes weiter nach oben gehört.

[CCRDude]

Deswegen fragte ich nach der benutzten Indy-Version ;)

In aktuellem Indy ist es ja scheinbar schon gefixt, da wäre es aus meiner Sicht sinnvoller, das Indy selber zu aktualisieren als es zu patchen, weil das nur eine weitere Fehlerquelle ist. Beispiel: ich hab neulich die JCL gepatcht. Bug behoben, und Monate später steige ich auf Packages um und suche mir nen Wolf, da etwas plötzlich nicht mehr funktioniert. Dabei kam raus, daß das kompilierte Package den Patch noch nicht drin hatte.

In diesem Sinne war das nur ein unklar ausgedrückter Hinweis aufs updaten ;)

[DeddyH]

Nein, was ich meinte: er hat den Code gepatcht und die geänderten Stellen kenntlich gemacht. Du aber sagst, in Deiner Version sei der Patch bereits enthalten, im gezeigten Code ist genau das aber nicht der Fall, die Zuweisung, um die es geht, steht immer noch an der alten Stelle. Aber generell hast Du Recht: wenn man selbst Fremdcode korrigiert läuft man immer Gefahr, nach einem Update wieder längst behobene Fehler zurückzuholen, das ist aber kein spezielles Indy-Problem (OK, hast Du ja auch nicht behauptet).

[CCRDude]

Aaaah...

Die Zuweisung ist im "neueren" Indy 10 zwar immer noch an der alten Stelle, was in diesem Fall aber keine Rolle mehr spielt, da AValue an SendTransferType übergeben wird, das so nicht mehr von FTransferType abhängt.

Insofern ist das Problem im gezeigten Code durchaus schon behoben, nur anders, als es BlueStarHH gemacht hat :)

[DeddyH]

Oh stimmt, das Parameterchen hatte ich übersehen. Dann nehme ich alles zurück und behaupte das Gegenteil :lol: