A partir du premier / il faut detecter '.' qui correspond a l'extension du fichier et detecter si il s'agit d'un cgi. Dans ce cas on recupere tout ce qui suit l'extension pour le PATH_INFO. On extrait ensuite la query_string dans le PATH_INFO.
Si l'extension n'est pas un cgi on se contente de purger la query_string.
Incoveneint: on ne peut pas avoir de directory contenant un '.' dans l'uri.
OU ALORS
A la maniere d'Apache et de nginx on ne se base pas sur l'extension du fichier mais sur l'uri. Par exemple une uri commencant par /cgi-bin va matcher avec une location /cgi-bin qui autorise l'execution de scripts dans le repertoire. Le serveur va alors considerer que le / suivant cgi-bin represente la ressource et que les / suivants font partie du PATH_INFO.
Dans la mesure ou on va utiliser l'extension du fichier script pour determiner quel interpreter utiliser je pense que la premiere option est la meilleure.
http://example.com:8080/path/to/script.py/extra/info?arg1=1&arg2=2 | || | | |
A partir du premier / il faut detecter '.' qui correspond a l'extension du fichier et detecter si il s'agit d'un cgi. Dans ce cas on recupere tout ce qui suit l'extension pour le PATH_INFO. On extrait ensuite la query_string dans le PATH_INFO. Si l'extension n'est pas un cgi on se contente de purger la query_string. Incoveneint: on ne peut pas avoir de directory contenant un '.' dans l'uri.
OU ALORS
A la maniere d'Apache et de nginx on ne se base pas sur l'extension du fichier mais sur l'uri. Par exemple une uri commencant par /cgi-bin va matcher avec une location /cgi-bin qui autorise l'execution de scripts dans le repertoire. Le serveur va alors considerer que le / suivant cgi-bin represente la ressource et que les / suivants font partie du PATH_INFO.
Dans la mesure ou on va utiliser l'extension du fichier script pour determiner quel interpreter utiliser je pense que la premiere option est la meilleure.