2009-06-29 3 views
4

Est-il possible d'écrire un filtre de servlet pour inspecter les codes de réponse HTTP?Est-il possible d'écrire un filtre de servlet pour inspecter les codes de réponse HTTP?

Je souhaite écrire un filtre qui inspectera de manière non destructive les codes de réponse HTTP sortants. Mais, il ne semble pas y avoir une méthode semblable à getResponseCode() sur l'objet Response.

Je ne comprends pas non plus comment les exceptions non gérées de la servlet sont censées être traitées. Je ne veux vraiment pas que ce filtre définisse quoi que ce soit. Passif est bon.

Des idées?

(Mon autre approche consiste à écrire une valve Tomcat personnalisée, mais ce n'est pas portable.)

+0

Comment est-ce que j'ai posé la question première, mais _ "a été posé cette question et a déjà une réponse. "L'autre question est venue deux mois plus tard. N'est-ce pas le duplicata? –

Répondre

7

vous pouvez envelopper votre réponse sortante à l'aide HttpServletResponseWrapper:

class GetStatusWrapper extends HttpServletResponseWrapper { 

    private int status; 

    GetStatusWrapper(HttpServletResponse response) { 
     super(response); 
    } 

    @Override 
    public void setStatus(int sc) { 
     super.setStatus(sc); 
     status = sc; 
    } 

    public int getStatus() { 
     return status; 
    } 
} 

puis dans votre filtre:

public class GetStatusResponseFilter implements Filter { 

    @Override 
    public void doFilter(ServletRequest request, 
         ServletResponse response, 
         FilterChain filterChain) 
          throws IOException, ServletException { 
     GetStatusWrapper wrapper; 
     wrapper = new GetStatusWrapper((HttpServletResponse) response); 
     filterChain.doFilter(request, wrapper); 
     System.out.println("status = " + wrapper.getStatus()); 
    } 

    @Override 
    public void init(FilterConfig arg0) throws ServletException { 
    } 

    @Override 
    public void destroy() { 
    } 
} 
+0

OK, trois problèmes que j'ai rencontrés en implémentant ceci: ONE) Il y a d'autres méthodes qui définissent le statut, mais je les ai perdues (j'espère.) DEUX) si le statut n'est pas explicite défini (comme c'est le cas dans mes tests), est-ce que cela signifie que je peux sans risque supposer qu'il est 200 OK? TROIS) Que se passe-t-il si, par exemple, le super.sendRedirect() renvoie une erreur? Je commence à trouver cette approche trop verbeuse et je n'ai pas confiance que je vais capturer le SC avec autorité à 100% du temps. –

+0

1) ceci est seulement une implémentation de "voir si cela fonctionne". 2) absolument 3) c'est le vrai problème 4) IMHO il n'y a pas d'autres approches portables comme celui-ci; Il y a seulement quelques méthodes que vous devez remplacer – dfa

+0

OK, il est en production et semble fonctionner. Merci. A la fin, j'initialise le statut int à 200, remplace les diverses méthodes setStatus, sendError et sendRedirect avec des blocs try/catch internes. –

0

Envisageriez-vous d'écrire un wrapper proxy dans la classe de réponse originale? De cette façon, vous pouvez gérer les appels d'événements/méthodes sur l'objet.

+0

Oui, je suis flou sur les détails. Comment les exceptions non gérées seraient-elles traitées dans ce cas? Est-ce que mon wrapper de proxy serait retransmis dans la pile d'appels, où il pourrait être possible de changer le code d'état? (Je ne sais vraiment pas si c'est possible.) –

Questions connexes