Changer le style de l'autoindex de NGINX via un hook et deux fichier ?

pas mal je vais tester

reverse proxy!!! i'd like so much to have nginx on my 7800 without fighting with uhttpd 🙂

Pas mal cette implémentation de websocket en PHP.

avec Nginx version

et la configuration suivante :
location /hello/ {
proxy_pass http://localhost:5001;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}

J'ai juste changé le code pour se connecter à la socket dans front.html comme suit :
var ws, url = 'wss://"domain"/hello/';

et hop ça roule ! ;)

Du coup je fais du websocket en php sous https avec le même port (443) ;) merci nginx.

Il faut juste penser à lancer le "serveur" php via :
php -q ppws_server.php

Testé sous la dernière version de firefox

Allez un autre article qui va vous aidez à vous passer de Apache...

un aide mémoire sur Nginx ;)

et je copie ici l'intégralité pour l'effet streisand ;)

MERCI !!

article :

J'apprécie beaucoup le serveur web Nginx. Mais étant moins populaire et plus jeune qu'Apache, il n'est pas toujours facile de trouver les bonnes informations au bon moment. Je vous propose donc un petit aide-mémoire amélioré. Attention, il faut avoir un peu de connaissance du fonctionnement d'un serveur web et déjà installé nginx.

Tester sa configuration

Avant de redémarrer le serveur web et éventuellement de le planter le temps de trouver l'erreur (au hasard, un ";" oublié ou une accolade mal placée), il est bon de tester la configuration avec :
nginx -t
Configuration de base
Désactivation de l'affichage de la version de nginx sur les pages d'erreur

Afin d'éviter à un méchant pirate de l'Internet d'en savoir trop sur la version de notre bien aimé Nginx, mieux vaut désactiver son affichage. Dans /etc/nginx/nginx.conf :
server_tokens off;
Un premier hôte virtuel tout simple

server {
listen 80 ; #On écoute sur le port 80 (http)
listen 443; # Et aussi sur le 443 (https)
ssl_certificate /etc/nginx/cert/moncertificat.cert; #Chemin vers le certificat ssl
ssl_certificate_key /etc/nginx/cert/moncertificat.key; #Chemin vers la clef du certificat
server_name moi.fr; #Détermine à quoi le serveur répondra, pour les sous-domaines, domaines multiples...
root /home/mesfichiers; #Chemin vers les fichiers servis par cet hôte.

access_log /var/log/nginx/access.log; # Les logs peuvent être gérés globalement dans nginx.conf ou dans chaque hôte virtuel.
error_log /var/log/nginx/error.log;

location / {
index index.htm; # La page d'index sert donc /home/mesfichiers/index.htm
}
}

Nous voilà avec un hôte simple, qui répondra à moi.fr en http et https. Si l'on ne précise pas de chemin après moi.fr, index.htm sera servi. Sinon, soit un chemin vers une vraie page est spécifié, et elle sera servie, soit le chemin indiqué ne mène nulle part, et une erreur 404 sera renvoyée. Les éventuels sous-dossiers seront traités de la même façon : si je tente http://moi.fr/toto/ , si une page d'index dans toto existe, elle sera servie, sinon, j'obtiendrai une erreur 404.
Activer php

Pour l'instant, notre petit serveur ne fournira que des pages statiques, php ne sera pas interprété. Voilà comment y remédier. Mais attention, il ne s'agit ici que du lien entre nginx et php-fpm, pensez à adapter /etc/php5/fpm/php.ini à vos besoins !
Installer php-fpm

Rien de bien sorcier, il suffit d'un bon vieux apt-get install php5-fpm et le tour est joué. Suivant votre usage, il sera probablement utile d'ajouter d'autres modules php.
Lier nginx et php-fpm

Ici, il faut ajouter les lignes suivantes à votre hôte virtuel :

location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param HTTPS on;
try_files $uri =404;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_split_path_info ^(.+.php)(/.*)$;
include fastcgi_params;
}

On demande donc à nginx, pour tous les fichiers .php, de communiquer avec le port 9000 de localhost, l'index étant index.php et en autorisant https. Si l'on ne trouve pas la page php demandée, on renvoie une erreur 404 (try_files $uri =404;) . Les deux lignes suivantes permettent de gérer correctement les chemins des scripts ou donnés aux scripts. Et la dernière ligne permet d'inclure les paramètre globaux de fastcgi.
Options diverses
Autoriser l'indexation

Pour autoriser l'indexation des fichiers d'un répertoire ou dans un hôte virtuel, utiliser l'instruction :
autoindex on;
Paramétrer le serveur par défaut

Dans certains cas, si un visiteur arrive vers votre serveur sans utiliser un nom d'hôte correct, il peut être utile de l'envoyer vers un hôte virtuel spécifique. Les instructions default_server sont alors faites pour vous :
server {
listen 80 default_server;
listen 443 default_server ssl;
...
Redirection et réécriture
Redirection

Pour rediriger une adresse vers une autre, il convient de renvoyer un code http 301 :
server {
listen 80;
server_name vieilleadresse.fr;
return 301 nouvelleadresse.fr$request_uri?;
}
Ainsi, la requête vers vieilleadresse.fr/coucoulesamis.html sera redirigée vers nouvelleadresse.fr/coucoulesamis.html .
Forcer le https

Il est possible de la même façon de forcer le protocole https (ou http) en utilisant la réécriture :
server {
listen 80;
server_name moi.fr;
rewrite ^ https://$server_name$request_uri? permanent;
}
Comme vous le voyez, il suffit de demander à nginx d'ajouter https:// au schéma d'url demandé au serveur.
Gérer les accès à certains répertoires

En tant qu'administrateur avisé, il n'est pas certain que vous souhaitiez voir certains répertoires accessibles au commun des mortels depuis l'internet, en particulier certains dossiers contenant la configuration des applications web. En général, avec Apache et la plupart des serveurs http, vous utiliser un fichier .htaccess situé à la racine du dossier incriminé pour gérer cela. Las, Nginx ne gère volontairement pas le .htaccess, pour des raisons de performance. Mais ne vous en faites pas, les développeurs du projet ont tout de même pensé à vous.
Interdire l'accès à un répertoire

Pour interdire l'accès à un répertoire, il convient de procéder comme suit :
location /monrepertoiresecret/{
deny all;
}
Ainsi, on interdit l'accès au dossier mais pas à ses sous-répertoires. Pour que l'interdiction soit récursive, une légère modification s'impose :
location ~ ^/monrepertoiresecret/{
deny all;
}
Dans un hôte, il peut être souhaitable d'interdire l'accès à plusieurs dossiers. Mais comme nous sommes paresseux, et que l'on nous a appris que la duplication de code c'était mal, nous allons nous contenter d'une directive :
location ~ ^/(dossier1|dossier2|dossier3){
deny all;
}
Et l'accès à nos trois dossiers est interdit, récursivement, en une directive.
Accès protégé par mot de passe

Là aussi, il faut jouer avec les directives. Mais auparavant, il convient de préparer un fichier contenant le nom d'utilisateur et le mot de passe. Chaque ligne définit un couple identifiant/mot de passe, ainsi qu'un commentaire. Ce fichier doit être accessible par Nginx. Chaque ligne se compose comme suit :
utilisateur:mot_de_passe_chiffré:commentaire
Le commentaire est facultatif. Pour chiffrer votre mot de passe, vous pouvez utiliser la commande openssl passwd, à condition bien entendu que le paquet openssl soit installé sur votre système. La directive pour générer un accès protégé est la suivante :
location / {
auth_basic "Qui va là?"; #Ceci s'affichera en titre de l'invite de mot de passe
auth_basic_user_file /chemin/vers/votre/fichier/motdepasse;
}
Les règles pour la récursivité, etc. sont les mêmes que précédemment.
Factorisation

Il est utile de placer certaines directives dans tous les hôtes virtuels, pour des raisons de sécurité ou pour ne pas journaliser certains événements. Mais dupliquer, c'est mal, on y revient. Pour factoriser, il suffit de créer un fichier .conf, et d'y placer les instructions souhaitées. Par exemple, dans /etc/nginx/commun.conf :

location = /favicon.ico {
log_not_found off;
access_log off;
expires max;
}
location ~ /. {
deny all;
access_log off;
log_not_found off;
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}

Ces trois directives permettent, dans l'ordre, de ne pas journaliser les accès à favicon.ico, qu'ils soient réussis ou non; de refuser l'accès aux fichiers commençant par un point (généralement des fichiers système); et finalement de ne pas journaliser les accès à favicon.ico, qu'ils soient réussis ou non. Il suffit maintenant de les inclure dans chacun de nos hôtes virtuels :
server {
...
include /etc/nginx/commun.conf;
}
Ressources

Si vous comprenez l'anglais, ne manquez pas la lecture des "Pitfalls", les erreurs communes de configuration
Configuration Nginx : Wiki
NGinx : HTTPS en tout simplicité avec un certificat CAcert.org
Conclusion

Je pense que vous avez maintenant matière à vous rafraîchir la mémoire ou à commencer à vous amuser sérieusement. Je n'ai ici qu'effleuré les capacités de Nginx, mais je pense que beaucoup d'usages simples seront couverts. Je tiens à remercier Jean-Michel qui m'a fait découvrir Nginx.

Je suis un peu d'accord avec Lui...

sur mon NAS j'ai lighthttpd d'origine pour la connection à l'interface de DLINK.
J'ai cherokee pour mes projets web (comme owncloud, les flux rss etc...)
et j'ai nginx pour mes scripts de compilation à distance...

pourquoi 3 différents ? car ils n'ont pas tous les mêmes avantages / inconvénients.

c'est comme la technologie Java à toutes les sauces en entreprises.... y compris pour des sites web "semi" statique (je dis semi car c'est "juste" des CMS... :/)

je trouve cela "débile"...

L'informatique est hétérogène ET avec une centaine de solutions à chaque problème...
ne vous demandez pas quelle est LA meilleure mais Pourquoi il y en a 100... et vous reverrez peut être vos besoins...

Fréd (coup de gueule du lundi :x)

Une des première application de mon serveur Web NGINX à été de mettre en œuvre un serveur de synchronisation pour Firefox. Cette fonctionnalité de