AngularJS et de la Manipulation des Erreurs 404

Quelle est la meilleure façon de servir la bonne 404 avec une application AngularJS?

Un peu de contexte: je suis en train de construire un Angulaire de l'application et ont opté pour l'utilisation

$locationProvider.html5Mode(true);

parce que je veux que l'Url de paraître naturel (et impossible à distinguer d'un multi-page "traditionnel" web app).

Sur le côté serveur (un simple Python Flacon app), j'ai un fourre-tout gestionnaire qui redirige tout à l'angle d'application:

@app.route('/', defaults={'path': ''})
@app.route('/<path>')
def index(path):
    return make_response(open('Ang/templates/index.html').read())

Maintenant, je suis à essayer de comprendre quoi faire avec des erreurs 404. La plupart de l'angle d'applications que j'ai vu faire ce qui suit:

.otherwise({ redirectTo: '/' })

ce qui signifie qu'il n'y a aucun moyen qu'ils peuvent servir un bon 404.

Cependant, je préférerais de beaucoup de retour d'un bon 404, avec un code d'état 404 (principalement à des fins SEO).

Quelle est la meilleure façon de gérer une erreur 404 Angulaire? Dois-je vous inquiétez pas à ce sujet et le bâton avec un fourre-tout? Ou devrais-je supprimer le fourre-tout et de servir de bon 404 sur le serveur?

édité pour plus de clarté

  • que voulez-vous faire sur 404 pourriez-vous parler de votre cas d'utilisation
  • Lorsque l'on visite /fasd, on devrait être redirigé vers une page d'erreur 404: "désolé, la page que vous tentez d'accéder n'existe pas". Un code d'état 404 doit être retourné.
  • vous avez la possibilité d'enregistrer une réponse de l'intercepteur et vérifier le code d'état dans l'intercepteur, vous trouverez 404 dans le code d'état http, vous pourrait rediriger vers n'importe quel chemin à l'aide de $lieu.chemin ("path")
InformationsquelleAutor Ryan | 2013-07-08
  1. 32

    Je pense que vous confondez Flacon routes Angulaire routes.

    L'erreur 404 code fait partie du protocole HTTP. Un serveur web utilise comme une réponse à un client lorsque l'URL demandée n'est pas connu par le serveur. Parce que vous mettez un fourre-tout dans votre Flacon serveur vous ne serez jamais obtenir un 404, Flacon appelle votre fonction d'affichage pour toutes les Url que vous tapez dans la barre d'adresse. À mon avis, vous ne devriez pas avoir un fourre-tout et laissez Flacon de répondre avec 404 lorsque l'utilisateur tape une URL non valide dans la barre d'adresse, il n'y a rien de mal à cela. Flacon vous permet même d'envoyer une page personnalisée lorsqu'un code 404 est retourné, de sorte que vous pouvez faire de la page d'erreur ressembler le reste de votre site.

    Sur le côté Angulaire, il n'y a vraiment aucune transaction HTTP parce que tout le routage interne à l'application qui se passe dans le client sans que le serveur même le savoir. Cela peut être une partie de votre confusion, Angulaire liens sont gérées entièrement par le client, sans toute demande faite sur le serveur, même dans html5mode, donc il n'y a pas de concept d'une erreur 404 dans ce contexte, tout simplement parce que il n'y a pas de serveur de participation. Angulaire lien qui vous envoie à une route inconnue sera simplement tomber dans le otherwise clause. La bonne chose à faire ici est d'afficher un message d'erreur (si l'utilisateur a besoin de savoir sur cette condition et peut faire quelque chose) ou tout simplement ignorer la route inconnue, comme la redirectTo: '/' n'.

    Cela ne semble pas être votre cas, mais si en plus de servir de l'Angulaire de l'application de votre serveur mis en place une API qui Angulaire pouvez l'utiliser pendant qu'il s'exécute, puis Angulaire pourrait obtenir un 404 de Flacon si il fait une requête asynchrone à cette API à l'aide d'une URL non valide. Mais vous ne voulez pas afficher une page d'erreur 404 de l'utilisateur si ce qui s'est passé, puisque la demande a été interne à l'application et ne sont pas déclenchées par l'utilisateur directement.

    J'espère que cela aide à clarifier la situation!

    • Je vais enlever le fourre-tout, parce que je veux être en mesure de servir la bonne erreurs 404 (pour le RÉFÉRENCEMENT, etc.). Cependant, maintenant je dois garder une liste de routes pour Flacon à col sur Angulaire. Cela signifie que chaque fois que j'ajoute une nouvelle route, j'ai besoin de l'ajouter à mes deux app.js et mon controllers.py. Mais honnêtement, j'aimerais juste un seul point de la vérité. Comment pourrais-je mettre à jour les routes dans un endroit et d'avoir leur auto-traduit à la fois dans le JS et le code python? Je pensais à la création d'un fichier JSON avec les itinéraires (le python importer les routes et une nouvelle app.js serait généré lorsque le fichier JSON est touché).
    • Vous êtes encore confus le serveur et côté client. Votre ballon d'application a qu'une seule route, la "/" qui sert l'Angulaire de l'application du client. C'est tout. L'angle d'application peut définir autant de voies qu'il a besoin, mais ceux-ci sont côté client, le Flacon serveur n'est pas impliqué dans ces. En effet, avec une telle configuration simple il est clair pour moi pourquoi vous avez besoin de ballon sur le serveur, il semble que vous êtes seulement à servir les fichiers statiques de votre Angulaire de l'application.
    • Je ne suis pas de les confondre. Considérez ceci: j'ai mon angulaire de l'application avec des "/" et "/à propos de" à l'angle des routes. J'ai aussi html5Mode activé. Cela signifie que si l'utilisateur passe à "/", une requête sera envoyée au serveur et l'angulaire de l'application se lance. Lorsque l'utilisateur accède à "/à propos de", la demande ne pourra pas aller sur le serveur, depuis l'angle d'application est actuellement de le manipuler. Toutefois, si l'utilisateur actualise la page "/à propos de" sera envoyé au serveur. Que signifie, il doit y avoir un "/à propos de" point de terminaison sur le serveur qui transmet la demande sur angulaire.
    • Désolé, oui, si vous voulez que l'utilisateur puisse accéder à l'application à partir de la liens qui s'affichent dans la barre d'adresse vous devez ensuite configurer le serveur pour réécrire les URLs de "/" de sorte que la principale application est toujours servi. Je viens de trouver ce dans l'angle de la documentation concernant la mode html5: "l'Utilisation de ce mode nécessite la réécriture d'URL sur le côté serveur, fondamentalement, vous avez de réécriture de tous vos liens vers le point d'entrée de votre application (par ex. index.html)"
    • Exactement. Et cela peut être assez ennuyeux, car vous risquez de vous retrouver à la modification d'une URL dans votre Angulaire de code, mais oublient de le faire dans le code serveur. Il n'est également pas très élégant. Voici ce que j'ai fait: (1) mettre le routage de l'info dans un fichier JSON (2) mettre en place mon serveur afin d'en extraire les points de terminaison dans les routes et ont les effets de retour "index.html" (angulaire de la poignée) (3) a écrit un script pour re-générer un nouveau app.js à partir du fichier JSON à chaque fois que le serveur démarre. -- Toutefois, de l'OMI, c'est aussi assez inélégant et je suis tout à fait satisfait. Souhaitons qu'il y a une meilleure façon.
    • Ou vous pouvez simplement suivre la suggestion donnée par l'angle de gars et de mettre en œuvre la réécriture d'url, ce qui semble plus facile et plus propre.
    • C'est ce que j'avais à l'origine. Donc, " / " et "/à propos de" retournent "index.html". Cependant, comme je l'ai dit avant, vous avez encore de mettre à jour en permanence les points de terminaison à deux endroits.
    • La réécriture d'URL est quelque chose que vous configurez sur votre serveur web, pas sur le Flacon. Vous pouvez avoir Apache, nginx, etc. modifier l'Url entrantes afin que votre ballon serveur ne voit jamais "/". Vous n'êtes pas de la planification du déploiement de votre site sur le Flacon serveur web, non? Ce n'est pas un serveur de production.
    • Oui je me rends compte de la Fiole serveur web n'est pas un serveur web de production, donc j'utilise Gunicorn et de la déployer sur Heroku. Une idée de comment faire cela avec Heroku? Quel est le problème avec le fait d'avoir le ballon serveur retourne le seul modèle pour l'angle d'application? La latence?
    • gunicorn est plus le serveur de base, je crois que vous pourriez mettre en œuvre la réécriture à l'aide de la pre_request crochet, mais je n'ai jamais essayé, vous ne savez pas si cela fonctionne. Je pense que nous avons fait un cercle complet, si vous aviez à mettre en Flacon (et il me semble que c'est le seul choix raisonnable), puis le fourre-tout de l'itinéraire que vous avez commencé avec est la meilleure façon, parce que vous ne voulez pas d'avoir le côté client routes dupliqué sur le serveur. Vous n'obtiendrez jamais une 404 de Flacon puis, et si un client côté de la route n'est pas valide, vous pouvez juste de redirection "/" angulaires, ou afficher une erreur si vous préférez.
    • En fait je n'aime pas le catch-all idée, car comme vous l'avez dit, une erreur 404 ne sera pas servi. Ce que j'ai fait était d'avoir Flacon de redirection à l'angle de l'application que si une route donnée existé. Sinon, il serait une erreur 404. J'ai conçu mes itinéraires dans une manière que j'ai à faire minimal de mise à jour côté serveur - mon CRUD de style routes rediriger vers angulaire seulement si une URL de point de terminaison correspond à un modèle défini (et si un ID est spécifié, correspond à un objet existant dans la db). D'autres voies comme "/à propos de" je viens individuelle.
    • Une énigme! Si vous pouvez exécuter du JS côté serveur, vous pouvez déployer vos itinéraires fichier js et invoquer sur le serveur de décider de répondre avec HTTP 404... alors vous n'auriez pas à le mettre à jour dans deux endroits ... mais vous aurez à déployer sur le serveur à chaque fois que vous ajouter des itinéraires
    • J'aimerais gentiment remarquer que la réponse ci-dessus est un autre incorrecte, et à tort, indique la confusion de ma part qui n'était tout simplement pas là. Il serait agréable d'avoir ce reflète dans le début de la réponse.

    InformationsquelleAutor Miguel
  2. 17

    Après avoir joué un peu, ainsi que quelques discussions avec Miguel, j'ai compilé quelques-unes des solutions différentes:

    1. Il suffit d'utiliser un fourre-tout, et ne vous inquiétez pas bon 404. Cela peut être réglé avec le code côté serveur (comme dans ma solution originale), ou mieux, avec l'URL ré-écriture sur votre serveur web.
    2. Réserve une certaine partie de votre site pour votre angulaire de l'application (comme /app). Pour cette section, mettre en place un fourre-tout, et ne vous inquiétez pas bon 404. Vos autres pages vous seront servies régulièrement les pages et de les visiter URL invalide qui ne commence pas avec /app le résultat sera une bonne 404.
    3. Constamment assurez-vous que tous vos itinéraires app.js sont mis en miroir dans votre code côté serveur (oui, assez gênant), où vous aurez un de ces routes servent angulaire de votre application. Tous les autres itinéraires de 404.

    P. S. La deuxième option est mon favori personnel. Je l'ai essayé et il fonctionne très bien.

    • Je suis confronté à un problème similaire avec un rapporteur d'angle / node.js la pile. J'ai un itinéraire qui utilise un code spécifique pour la recherche de données. Pour une bonne URL cela fonctionne bien. Pour une mauvaise URL que j'ai juste le vent avec une fracture à la recherche de la page web. L'url ressemble à: /details/goodID vs détails/badID (j'ai aussi remarqué que certains robots comme pour essayer /détails/détails/goodID qui est également une mauvaise route :/). Solution n ° 2 n'a pas vraiment gérer ce cas, et j'aimerais éviter de #3 si possible. Avez-vous courir à travers toutes les autres idées? Est-il un 404-ish façon de rendre compte de l'erreur côté client??
    • concernant le #3, exigeant une les itinéraires module avec toutes les définitions via browserify n'est pas mauvais en droit? C'est la façon dont j'ai été le faire de toute façon.
    • Pardonnez-moi, mais ne ce serveur d'appel de nier le point de l'ensemble des Clients du SPA? Nous appelons un SPA une fois et l'utilisation de l'Api via Ajax à partir de là. Si vous devez aller à votre serveur pour chaque point de terminaison, alors pourquoi ne pas simplement utiliser le modèle client/serveur?
    InformationsquelleAutor Ryan
  3. 2

    C'est un vieux thread, mais je cam à travers elle tout en cherchant la réponse.

    Ajouter ceci à la fin de votre appRoutes.js et de faire un 404.html vue.

    .when('/404', {
    templateUrl: 'views/404.html',
    controller: 'MainController'
})

.otherwise({ redirectTo: '/404' })
    InformationsquelleAutor Russ
  4. 0

    Je pense qu'un vrai http 404 va être assez inutile "pour les fins de SEO" si vous ne servez pas utilisable non-javascript, le contenu réel des pages de votre site. Un indexeur de recherche est peu probable d'être en mesure de rendre votre angulaire site pour l'indexation.

    Si vous êtes inquiet à propos de SEO, vous aurez besoin d'une sorte de côté de serveur de façon à rendre le contenu de votre angulaire pages sont rendu. Si vous avez cela, l'ajout d'une erreur 404 pour des Url non valide est la partie la plus facile du problème.

    InformationsquelleAutor rjmunro
  5. -2

    Ici est la meilleure façon de gérer l'erreur et fonctionne très bien

    function ($routeProvider, $locationProvider, $httpProvider) {
    var interceptor = [
        '$rootScope', '$q', function (scope, $q) {

            function success(response) {
                return response;
            }

            function error(response) {
                var status = response.status;

                if (status == 401) {
                    var deferred = $q.defer();
                    var req = {
                        config: response.config,
                        deferred: deferred
                    };
                    window.location = "/";
                }

                if (status == 404) {
                    var deferred = $q.defer();
                    var req = {
                        config: response.config,
                        deferred: deferred
                    };
                    window.location = "#/404";
                }
                // otherwise
                //return $q.reject(response);
                window.location = "#/500";
            }

            return function (promise) {
                return promise.then(success, error);
            };

        }
    ];
    $httpProvider.responseInterceptors.push(interceptor);
});

// routes
app.config(function($routeProvider, $locationProvider) {
    $routeProvider
        .when('/404', {
            templateUrl: '/app/html/inserts/error404.html',
            controller: 'RouteCtrl'
        })
        .when('/500', {
            templateUrl: '/app/html/inserts/error404.html',
            controller: 'RouteCtrl'
        })

        ......

   };
    • Je n'ai pas downvote - mais je sais préfère des réponses qui ne sont pas strictement le code. Juste une suggestion, je suis reconnaissant pour la plupart des gens qui passe leur temps passé à répondre aux questions des autres.
    • Il ne résout pas le problème...
    InformationsquelleAutor Mike Jones