Un 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

Je 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 ?

Moi 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?

Le 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.

FastCGI is your friend

+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

En 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.

Justement 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?

Tu devrais recevoir tout ça dans FCGI_PARAMS, non ?...

http://www.fastcgi.com/devkit/doc/fcgi-spec.html#S6.2

Pas 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

Je 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

T'es sûr que ton FastCGI est bien en remote?

Il 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...

AJP13 fournit bien tous les headers

http://img142.imageshack.us/img142/2089/ajp13testes6.jpg

Oui je sais, j'aime bien implémenter les protocoles

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

J'ai beau modifier la config à foison, lighttpd n'a pas l'air de passer ces infos

Je n'ai que cela:



C'est vachement limité

Moi 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)...

J'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é