9
votes

Nginx hashbang réécrire

Je me demande quel emplacement ou réécrire la directive Nginx pour les URL de hashbang (#!) ressemblerait. En gros, acheminez toutes les URL non frappées par hashs à travers le hashbang comme un contrôleur avant. Donc:

http://example.com/#!/about/staff


0 commentaires

3 Réponses :


11
votes

pour les identificateurs de GET fragment ne semblent pas / ne devrait pas (certains clients bogués les envoyer) dans une requête HTTP, de sorte que vous ne pouvez pas avoir une règle de réécriture pour les faire correspondre, quel que soit webserver.

Le moteur HTTP ne peut pas faire de suppositions à ce sujet. Le serveur est même pas donné il. p> Blockquote>

Si vous avez essayé de faire la demande initiale / redirection vers / #! plutôt que de servir l'indice racine, vous finiriez avec une erreur « trop de redirection », comme le client reviendrait demander / nouveau (rappelez-vous qu'il ne sera pas envoyer le # à sa demande). Vous aurez besoin de le faire avec javascript plutôt que pour le document d'index strong>. P>

La ligne de fond est que ce n'est pas côté serveur disponible dans la demande GET. Même boucle a été patché de ne pas envoyer plus. P>

vous pourriez avoir des directives de localisation nginx pour faire tout le reste a frappé le contrôleur avant que: p>

 location = / {
  }      

  location = /index.html {
  }      

  location ~ / {
    rewrite ^ /#!$uri redirect;
    break;
  }


1 commentaires

Une meilleure alternative serait la directive try_files . Peut-être que ce n'était pas là quand cela a été répondu. Voir ma réponse



2
votes

comme une modification de ce qui précède, je ne fais que cette redirection pour des appels spécifiques, et ne recevez donc aucune boucle potentielle:

location ~ /login|/logout|portfolios|/portfolio/*|/public/* {
  rewrite ^ /#!$uri permanent;
  break;
}


0 commentaires

-1
votes

Le meilleur itinéraire consiste à utiliser la directive try_files : xxx

supposant que votre fichier index.html contient la logique JavaScript que les itinéraires le hash à la bonne ressource. L'URI restera ce que le visiteur a demandé que NGinx ait simplement des itinéraires de la demande à votre fichier d'index lorsque aucun fichier de correspondance réel ne peut être trouvé pour l'URI de la demande.


1 commentaires

Manquez-vous un '~' wes?