2009-08-18 8 views
4

J'ai écrit un HttpModule que j'utilise pour intercepter les appels du gestionnaire WebResource.axd afin que je puisse effectuer un post-traitement sur le javascript.Le filtre HttpResponse ne renvoie rien

Le module encapsule le flux Response.Filter pour effectuer son traitement et écrit ses modifications dans le flux sous-jacent.

Le problème que j'ai, c'est que le script ne retourne pas dans le navigateur.

Ainsi, comme exemple très simple que tout agit comme un laissez-passer à travers, le module ressemble à ceci:

public class ResourceModule : IHttpModule 
{ 
    public void Dispose() 
    { 
    } 

    public void Init(HttpApplication context) 
    { 
     context.PostRequestHandlerExecute += new EventHandler(context_PostRequestHandlerExecute); 
    } 

    void context_PostRequestHandlerExecute(object sender, EventArgs e) 
    { 
     HttpApplication context = sender as HttpApplication; 

     if (context.Request.Url.ToString().Contains("WebResource.axd")) 
     { 
      context.Response.Filter = new ResourceFilter(context.Response.Filter); 
     } 
    } 
} 

et le ResourceFilter qui vient en sortie ce qu'il reçoit ressemble à ceci:

public class ResourceFilter : MemoryStream 
{ 
    private Stream inner; 

    public ResourceFilter(Stream inner) 
    { 
     this.inner = inner; 
    } 

    public override void Write(byte[] buffer, int offset, int count) 
    { 
     inner.Write(buffer, offset, count); 
    } 
} 

Je peux attacher et voir le module et le filtre invoqué, mais quand je navigue vers l'URL de WebResource.axd je ne reçois rien en retour.

J'ai utilisé ce modèle pour implémenter des modules qui effectuent un traitement sur des pages aspx et ils fonctionnent très bien. Il semble qu'il y ait quelque chose à propos de l'interaction avec WebResource.axd qui empêche ce fonctionnement.

Répondre

5

J'ai fait un petit projet et recréé votre problème exactement. J'exécutais fiddler pour avoir un bon aperçu de la réponse, y compris les en-têtes et j'ai trouvé que c'était uniquement sur les filtres des fichiers * .axd. Après quelques recherches, j'ai trouvé this article par Daniel Richardson qui avait le même problème.

Il s'avère que le System.Web.Handlers.AssemblyResourceLoader (que les axds traversent) définit un indicateur pour ignorer d'autres écritures.

Daniel donne un exemple d'utilisation de la réflexion pour désactiver ce drapeau et permettre à votre filtre de fonctionner sur le résultat de l'axd. Je l'ai essayé et ça marche bien. Il vaut mieux garder à l'esprit tout impact sur les performances, et comme le dit Daniel, les implémentations ASP.NET pourraient changer.

+0

Si quelqu'un est intéressé par le code pour définir le drapeau à faux : 'champ FieldInfo = _webStream.GetType() BaseType.GetField ("_ écrivain", BindingFlags.NonPublic | BindingFlags.Instance),' ' var = écrivain field.GetValue (_webStream)' ' FieldInfo ignoringWrites. = writer.GetType(). GetField ("_ ignoringFurtherWrites", BindingFlags.NonPublic | BindingFlags.Instance); ' ' ignoringWrites.SetValue (writer, false); ' – avidenic

1

Sur la base de mon expérience, le filtre doit être « accros » en cas PreRequestHandlerExecute au plus tard pour le faire fonctionner dans IIS version antérieure à la version 7.

Questions connexes