Programmation » FastCGI ou AJP13 ...
FastCGI ou AJP13 ...
Publié le 12/12/2006 @ 10:07:41,
Par rfrUn petit débat de développeur, ça manque ici
Dans l'optique d'un application serveur, et pour ne pas développer tout le protocole HTTP, à votre avis, le meilleur connecteur à utiliser/implémenter, c'est ???
Sachant que AJP13 (utilisé pour tomcat par ex...) et plus simple, utilise un code unique pour les header les plus courants, évite les problèmes liés au passage par variable d'environnement, mais possède quelques petites limitations (genre taille du header de la requête limité à 8k).
Je suppose que FastCGI, tout le monde voit
AJP13: http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html
FastCGI: http://www.fastcgi.com/devkit/doc/fcgi-spec.html
Dernière édition: 12/12/2006 @ 10:11:10
Dans l'optique d'un application serveur, et pour ne pas développer tout le protocole HTTP, à votre avis, le meilleur connecteur à utiliser/implémenter, c'est ???
Sachant que AJP13 (utilisé pour tomcat par ex...) et plus simple, utilise un code unique pour les header les plus courants, évite les problèmes liés au passage par variable d'environnement, mais possède quelques petites limitations (genre taille du header de la requête limité à 8k).
Je suppose que FastCGI, tout le monde voit
AJP13: http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html
FastCGI: http://www.fastcgi.com/devkit/doc/fcgi-spec.html
Dernière édition: 12/12/2006 @ 10:11:10
To die is a time consuming activity, it often takes a lifetime (but some are faster than others ... though)
FastCGI ou AJP13 ...
Publié le 12/12/2006 @ 10:13:34,
Par philfrJe dirais que ça dépend du langage dans lequel tu veux développer ton appli web... Et en soi, choisir le langage et la plateforme va déjà te laisser beaucoup moins le choix du connecteur.
J'ai l'impression que tu poses le problème à l'envers, non ?
J'ai l'impression que tu poses le problème à l'envers, non ?
FastCGI ou AJP13 ...
Publié le 12/12/2006 @ 10:21:59,
Par rfrMoi je dirais pas vraiment ... rien n'empêche d'implémenter AJP13 coté serveur en C/C++ ... Je n'aime d'ailleurs pas l'aspect "torturé" de FastCGI. C'est vrai que son modèle d'utilisation est plus évolué (filter, responder, authorizer) mais qui utilise autre chose que le responder?
Dernière édition: 12/12/2006 @ 10:24:25
Dernière édition: 12/12/2006 @ 10:24:25
To die is a time consuming activity, it often takes a lifetime (but some are faster than others ... though)
FastCGI ou AJP13 ...
Publié le 12/12/2006 @ 10:57:40,
Par philfrLe but du connecteur est justement de ne pas avoir à l'implémenter, mais d'utiliser les libs existantes dans ton langage...
Si tu dois faire du C/C++ côté serveur, utilise FastCGI.
Si tu dois faire du C/C++ côté serveur, utilise FastCGI.
FastCGI ou AJP13 ...
Publié le 12/12/2006 @ 13:22:24,
Par zion+1 pour FastCGI et c'est pas si torturé que cela... Y a juste les variables d'environnement qui font chier si tu fais un FastCGI en remote
Je suis le Roy
FastCGI ou AJP13 ...
Publié le 12/12/2006 @ 13:38:22,
Par philfrEn FastCGI, y'a pas de problème de variables d'environnement...
Il n'y a que FCGI_WEB_SERVER_ADDRS qui soit passé au démarrage, tout ce qui concerne les requêtes passe par le socket...
C'est le CGI qui passe un tas de trucs en environnement.
Il n'y a que FCGI_WEB_SERVER_ADDRS qui soit passé au démarrage, tout ce qui concerne les requêtes passe par le socket...
C'est le CGI qui passe un tas de trucs en environnement.
FastCGI ou AJP13 ...
Publié le 12/12/2006 @ 15:15:57,
Par zionJustement phil, j'en ai besoin de ces variables et il les envoie pas
Exemple, il me faut le USER_AGENT, le FastCGI est en responder en remote... Je fais comment pour avoir l'USER_AGENT moi?
Il ne me passe que le type de serveur (supaire) et l'ip du mec... mais et à part ça?
Exemple, il me faut le USER_AGENT, le FastCGI est en responder en remote... Je fais comment pour avoir l'USER_AGENT moi?
Il ne me passe que le type de serveur (supaire) et l'ip du mec... mais et à part ça?
Je suis le Roy
FastCGI ou AJP13 ...
Publié le 13/12/2006 @ 13:13:56,
Par philfrTu devrais recevoir tout ça dans FCGI_PARAMS, non ?...
http://www.fastcgi.com/devkit/doc/fcgi-spec.html#S6.2
http://www.fastcgi.com/devkit/doc/fcgi-spec.html#S6.2
FastCGI ou AJP13 ...
Publié le 13/12/2006 @ 13:45:35,
Par zionPas du tout, il n'y a que quelques paramètres dans FCGI_PARAMS, ils ne contiennent pas du tout l'USER_AGENT ou tout ce qui viendrait directement de l'utilisateur (le FORWARDER_FOR etc, etc).
J'ai même jeté un oeil dans le STDIN pour voir si c'était là, négatif.
Franchement pour un truc qui est censé gérer le load balancing et compagnie, comment ils peuvent oublier un truc aussi con? Ou alors j'ai loupé un épisode mais jusque là pas moyen d'avoir trace de ces infos
J'ai même jeté un oeil dans le STDIN pour voir si c'était là, négatif.
Franchement pour un truc qui est censé gérer le load balancing et compagnie, comment ils peuvent oublier un truc aussi con? Ou alors j'ai loupé un épisode mais jusque là pas moyen d'avoir trace de ces infos
Je suis le Roy
FastCGI ou AJP13 ...
Publié le 13/12/2006 @ 14:04:02,
Par philfrJe viens de bricoler un sample...
J'ai bien le HTTP_USER_AGENT et toutes les variables CGI
http://img150.imageshack.us/img150/5339/snapshot3hb9.png
J'ai bien le HTTP_USER_AGENT et toutes les variables CGI
http://img150.imageshack.us/img150/5339/snapshot3hb9.png
FastCGI ou AJP13 ...
Publié le 13/12/2006 @ 14:06:24,
Par rfrT'es sûr que ton FastCGI est bien en remote?
To die is a time consuming activity, it often takes a lifetime (but some are faster than others ... though)
FastCGI ou AJP13 ...
Publié le 13/12/2006 @ 14:17:46,
Par philfrIl est pas en remote, mais il ne fait que lire ce qui entre sur son socket.
Je tente de le faire en remote pour être sûr...
Je tente de le faire en remote pour être sûr...
FastCGI ou AJP13 ...
Publié le 13/12/2006 @ 15:54:28,
Par rfrAJP13 fournit bien tous les headers
http://img142.imageshack.us/img142/2089/ajp13testes6.jpg
Oui je sais, j'aime bien implémenter les protocoles
Dernière édition: 13/12/2006 @ 15:56:16
http://img142.imageshack.us/img142/2089/ajp13testes6.jpg
Oui je sais, j'aime bien implémenter les protocoles
Dernière édition: 13/12/2006 @ 15:56:16
To die is a time consuming activity, it often takes a lifetime (but some are faster than others ... though)
FastCGI ou AJP13 ...
Publié le 13/12/2006 @ 17:03:36,
Par zionJe viens de bricoler un sample...
J'ai bien le HTTP_USER_AGENT et toutes les variables CGI
J'ai bien le HTTP_USER_AGENT et toutes les variables CGI
Sources
Et avec quel serveur aussi?
Lighttpd ne m'envoie qu'une liste très réduite de headers, peut être que c'est lui le coupable soit dit en passant
Je suis le Roy
FastCGI ou AJP13 ...
Publié le 18/12/2006 @ 20:38:06,
Par zionJ'ai beau modifier la config à foison, lighttpd n'a pas l'air de passer ces infos
Je n'ai que cela:
SERVER_SOFTWARE = lighttpd/1.4.4
SERVER_NAME = 192.168.100.3
GATEWAY_INTERFACE = CGI/1.1
SERVER_PORT = 80
SERVER_ADDR = 192.168.100.3
REMOTE_PORT = 2291
REMOTE_ADDR = 192.168.100.2
SCRIPT_NAME = /tests/test.klm
C'est vachement limité
Je n'ai que cela:
SERVER_SOFTWARE = lighttpd/1.4.4
SERVER_NAME = 192.168.100.3
GATEWAY_INTERFACE = CGI/1.1
SERVER_PORT = 80
SERVER_ADDR = 192.168.100.3
REMOTE_PORT = 2291
REMOTE_ADDR = 192.168.100.2
SCRIPT_NAME = /tests/test.klm
C'est vachement limité
Je suis le Roy
FastCGI ou AJP13 ...
Publié le 18/12/2006 @ 21:42:25,
Par philfrMoi je l'ai fait avec apache (ce qui peut changer pas mal), et via localhost (ce qui ne devrait rien changer).
A l'occasion, je teste avec un autre serveur web et en vrai remote... Mais bon, c'est pas/plus mon métier non plus, alors t'as sûrement raison, mais c'est pas fastcgi qui est en cause (pour rembrayer sur la question de rfr)...
Dernière édition: 18/12/2006 @ 21:44:56
A l'occasion, je teste avec un autre serveur web et en vrai remote... Mais bon, c'est pas/plus mon métier non plus, alors t'as sûrement raison, mais c'est pas fastcgi qui est en cause (pour rembrayer sur la question de rfr)...
Dernière édition: 18/12/2006 @ 21:44:56
FastCGI ou AJP13 ...
Publié le 18/12/2006 @ 21:45:05,
Par zionJ'ai lu un rien la doc de lighttpd en long et en large, en fait il semblerait qu'il ne passe les informations qu'en local, en remote tu te fourres le tout très profond. C'est incompréhensible mais c'est comme cela on dirait
Apache ne fonctionnait pas du tout en FastCGI sous Windows pour ma part, je suis incapable de dire ce qu'il en est de son côté
Apache ne fonctionnait pas du tout en FastCGI sous Windows pour ma part, je suis incapable de dire ce qu'il en est de son côté
Je suis le Roy