Pourquoi le filtre d'appel de Tuckey Urrrewre ne peut-il pas faire correspondre une chaîne d'appel de filtre.dofilter après une règle?

StackOverflow https://stackoverflow.com/questions/5043593

Question

Utilisation de la framework de printemps ici ...

J'ai créé un filtre pour modifier le corps de réponse des fichiers CSS et si j'appelle une URL directement, elle fonctionne. Cependant, si une règle d'urlrewrite est assortie, le filtre est ignoré.

exemple: Dans web.xml:

<filter>
    <filter-name>UrlRewriteFilter</filter-name>
    <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
    <!-- skipping init params here for brevity -->
</filter>
<filter-mapping>
    <filter-name>UrlRewriteFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

<filter>
    <filter-name>cssFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
    <filter-mapping>
    <filter-name>cssFilter</filter-name>
    <url-pattern>*css</url-pattern>
</filter-mapping>

Il y a un mappage configuré comme celui-ci dans URLREWRITE.XML:

<rule>
    <from>/styles-special/(.*)$</from>
    <to last="true">/styles/$1</to>
</rule>

(Nous avons besoin de cela pour un certain nombre de raisons)

Donc, tout fichier * .CSS dont le chemin démarre w / "/ styles-spécial /" sera réécrit à "/ styles /" et le fichier cssfilter ne sera pas appelé, mais n'importe quel fichier * .CSS dont le chemin commence à / "/ styles /" va passer par le CSSFilter comme prévu.

J'ai essayé de modifier le modèle d'URL pour CSSfilter à un certain nombre d'options différentes, mais le même résultat. Il me semble que le filtre de Tuckey Urrrewrite n'appelle pas la chaîne.dofilter () après une réécriture, mais peut-être que c'est plus compliqué que cela?

Une idée de ce que le problème pourrait être ici? Est-ce que cette fonctionnalité attendue? Des solutions de contournement? ... Peut-être qu'un intercepteur ou un contrôleur est la voie à suivre ici?

Merci d'avance pour tout conseil à ce sujet !!


Remarque: en utilisant ce qui suit (comme suggéré par AXTAVT):

<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>

corrige le problème avec le chaînage et le filtre est exécuté. Cependant, j'obtiens l'erreur suivante:

java.lang.IllegalStateException: NO CONTENT
at org.mortbay.jetty.HttpGenerator.addContent(HttpGenerator.java:106)
at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:644)
at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:579)

Voici l'extrait de code de filtre:

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
    HttpServletRequest httpRequest = (HttpServletRequest) request;
    HttpServletResponse httpResponse = (HttpServletResponse) response;

    OutputStream out = httpResponse.getOutputStream();
    GenericResponseWrapper wrapper = new GenericResponseWrapper(httpResponse);

    chain.doFilter(request, wrapper);

    if(log.isDebugEnabled()) log.debug("doFilter: chain");

    String respBody = new String(wrapper.getData()); // this throws error
...

Était-ce utile?

La solution

When Tuckey UrlRewrite Filter rewrites a URL, it forwards request to the new URL instead of passing it down the filter chain. By default filters are not applied to the forwarded requests, so you need to configure it:

<filter-mapping>
     <filter-name>cssFilter</filter-name>
     <url-pattern>*css</url-pattern>
     <dispatcher>REQUEST</dispatcher>
     <dispatcher>FORWARD</dispatcher>
</filter-mapping>
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top