FastCGI
-
Hi!
Ich versuche mich gerade an FastCGI mit lightTPD als Webserver. Konfiguriert hab ich lightTPD so, dass es nur eine Instanz von meinem FastCGI-Binary erzeugt.
So, in meiner FastCGI-Applikation erstelle ich einen Socket und verbinde mich zu localhost und meinem im lightTPD-Config angegebenen Port. Das Verbinden per Connect klappt soweit auch.
Mein Problem ist jetzt nur, dass ich über den Socket nie etwas empfangeKleiner Auszug aus der Konfigurations-Datei:
# which extensions should not be handle via static-file transfer # # .php, .pl, .fcgi are most often handled by mod_fastcgi or mod_cgi static-file.exclude-extensions = ( ".php", ".pl", ".cgi", ".fcgi" ) fastcgi.server = ( ".fcgi" => ( ( "host" => "127.0.0.1", "bin-path" => "C:/fcgi/fcgi.exe", "port" => 42939, "min-procs" => 1, "max-procs" => 1 ) ) )
Damit sollte doch m.E. jeder Seitenaufruf mit ".fcgi" am Ende an mein FastCGI-Programm weitergeleitet werden? Im Browser rufe ich die Seite "http://127.0.0.1/index.fcgi" auf, worauf nur ein "404 - Not Found" angezeigt wird (und zwar recht flux).
Weiß jemand was ich falsch gemacht haben könnte? Ich warte einfach mit blockierendem recv auf Eingangssignale, aber nix kommt (recv liefert aber auch nicht <=0 zurück und im lightTPD-log steht nur "Server started.").
PS: Mit der offiziellen FastCGI-Bibliothek von fastcgi.com geht's überhaupt nicht, hab mich dann stundenlang durch die Sourcen gewühlt, es dann aber irgendwann aufgegeben..
-
Ich hab grad die Debug-Optionen in der Config-Datei entdeckt
2008-09-10 18:27:33: (request.c.294) fd: 6 request-len: 400 GET /bla.fcgi HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive 2008-09-10 18:27:33: (response.c.212) -- splitting Request-URI 2008-09-10 18:27:33: (response.c.213) Request-URI : /bla.fcgi 2008-09-10 18:27:33: (response.c.214) URI-scheme : http 2008-09-10 18:27:33: (response.c.215) URI-authority: localhost 2008-09-10 18:27:33: (response.c.216) URI-path : /bla.fcgi 2008-09-10 18:27:33: (response.c.217) URI-query : 2008-09-10 18:27:33: (response.c.267) -- sanatising URI 2008-09-10 18:27:33: (response.c.268) URI-path : /bla.fcgi 2008-09-10 18:27:33: (mod_access.c.135) -- mod_access_uri_handler called 2008-09-10 18:27:33: (response.c.382) -- before doc_root 2008-09-10 18:27:33: (response.c.383) Doc-Root : HTDOCS/ 2008-09-10 18:27:33: (response.c.384) Rel-Path : /bla.fcgi 2008-09-10 18:27:33: (response.c.385) Path : 2008-09-10 18:27:33: (response.c.433) -- after doc_root 2008-09-10 18:27:33: (response.c.434) Doc-Root : HTDOCS/ 2008-09-10 18:27:33: (response.c.435) Rel-Path : /bla.fcgi 2008-09-10 18:27:33: (response.c.436) Path : HTDOCS/bla.fcgi 2008-09-10 18:27:33: (response.c.453) -- logical -> physical 2008-09-10 18:27:33: (response.c.454) Doc-Root : HTDOCS/ 2008-09-10 18:27:33: (response.c.455) Rel-Path : /bla.fcgi 2008-09-10 18:27:33: (response.c.456) Path : HTDOCS/bla.fcgi 2008-09-10 18:27:33: (response.c.473) -- handling physical path 2008-09-10 18:27:33: (response.c.474) Path : HTDOCS/bla.fcgi 2008-09-10 18:27:33: (response.c.530) -- file not found 2008-09-10 18:27:33: (response.c.531) Path : HTDOCS/bla.fcgi 2008-09-10 18:27:33: (response.c.116) Response-Header: HTTP/1.1 404 Not Found
Anscheinend wird gar nicht erst versucht, den Aufruf an mein FastCGI-Programm umzuleiten
Weiß jemand zufällig, warum?
PS: Ich hab mir einfach mal erlaubt ein bisschen zu Cross-posten, einfach weil das ein so spezielles Thema zu sein scheint/schien. Die gleiche Frage steht also auch im Forum von lightTPD (auch mit keiner Antwort). Ich hoffe das ist ok, eben weil es keine Pipi-Frage ist (oder war? Mittlerweile hab ich ja eine neue/andere Frage). Jedenfalls @Mods, wenn's zu sehr gegen die Forum-Regeln verstößt => löschen
-
Hat sich übrigens erledigt, ich schreib mir jetzt einfach meinen eigenen Webserver (hoch leben die Semesterferien)