Discussion :

[Flackou]

Salut tout le monde,

Je suis en train d'essayer de mettre un peu d'ordre dans mon site, notamment en assurant une bonne gestion des URL et je tombe sur un os.

Je voudrais que les URL défectueuses (vers des controllers, actions, ou pages qui n'existent pas) soient traitées par l'erreur 404. Seulement, quand je tape une URL absurde, j'ai une erreur du style 'Unkown action' ou 'Routing Error'.

J'ai bien lu et compris le principe des map.connect, donc je vois comment traiter les URL correctes, mais comment faire pour les URL défaillantes?

Merci pour votre aide

[Taum]

Salut,

De mémoire, il me semble que lorsque Rails ne trouve aucune route, il lève une exception de type ActionController::RoutingError.
Tu peux récuperer cette exception en réimplémentant la méthode rescue_action dans ton ApplicationController, tu pourras alors afficher le template que tu veux, rediriger l'utilisateur vers une page adéquate, etc. (en fait tout ce que tu peux faire dans une action classique).

[Flackou]

Merci Taum. Décidément, tu mérites vraiment tes étoiles et tes plumes.

Ta réponse me convient, cependant je m'étonne qu'il n'existe pas un moyen plus simple de faire ça. Je trouve ça assez essentiel de pouvoir gérer toutes les URLs, ca me parait donc bizarre qu'on soit obligé de recourir à des levées d'exceptions pour s'en charger.

Toujours sur le sujet, qq questions:
Quand est levée la page 404.html du répertoire /public?
Pensez-vous qu'une action par défaut "bad_request", implémentée dans l'ApplicationController pourrait être une bonne solution?

[Taum]

Je trouve ça assez essentiel de pouvoir gérer toutes les URLs

En principe, tu gères tes URLs par le fichier routes.rb uniquement. Est-ce que ton problème viendrait plutôt d'une URLs que tu n'arrive pas à exprimer avec map.connect ?

Une URL non reconnue est considérée comme un cas exceptionnel, et donc géré comme tel : un exception est levée, et elle est récupérée dans rescue_action. Ça correspond finalement à la sémantique habituelle de Ruby : try/throw/rescue (avec la dose de magie habituelle dans Rails, qui te fournit la méthode rescue_action au lieu du rescue de Ruby).

Quand est levée la page 404.html du répertoire /public?

C'est l'implémentation par défaut de rescue_action qui essaye de faire correspondre le code d'erreur HTTP à l'exception levée (ici RoutingError -> 404 Not Found) et qui appelle le template correspondant dans le dossier public si il existe. Si tu ne réimplémente pas rescue_action (ou si tu appelle super), les pages 404.html, 500.html, etc. seront automatiquement utilisées.
(cf. la doc de ActionController::Rescue)

[Flackou]

Merci pour ces éclairages. C'est vrai que c'est finalement assez simple et cohérent cette démarche.

Y a juste une dernière chose que je comprends pas : tu me dis

Si tu ne réimplémente pas rescue_action (ou si tu appelle super), les pages 404.html, 500.html, etc. seront automatiquement utilisées.

Or dans mon cas, je n'ai pas réimplémenté rescue_action et ce n'est pas la page 404.html qui est utilisée en cas d'erreur, mais une autre page du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Unknown action
 
No action responded to bad_action

générée automatiquement. Pourquoi?

[Taum]

Ah, oui, tu obtiens la page de debug au lieu du 404.html

Ça vient du fait que tu es en environnement de développement. Tu as donc une page générée par Rails avec toute les infos de debug dont tu peux avoir besoin pour identifier ce qui a levé une exception (nom de l'exception, message associé, stacktrace etc.). En environnement de production, ta page sera bien affichée à tes visiteurs. Tu peux le vérifier en démarrant ton serveur avec : script/server -e production.

Cela permet au développeur d'avoir toutes les infos dont il a besoin, et aux visiteurs d'avoir une page d'erreur propre, avec éventuellement des liens utile, mais surtout pas de code ou d'infos potentiellement confidentielles.


Pour rentrer dans les détails :
- L'environnement de production active l'option consider_all_requests_local (cf. config/environments/development.rb)
- Cette option fait que rescue_action va appeller rescue_action_locally au lieu de rescue_action_in_public (in public -> pour les visiteurs).
- rescue_action_locally se charge d'afficher les infos de debug

Quand je disais que Rails affichait le template du dossier public/, il s'agissait bien sur de rescue_action_in_public.

[Flackou]

OK, c'est parfaitement clair maintenant! J'avais pas pensé à l'environnement de développement, me voilà donc rassuré.
Merci beaucoup pour ces infos!