2009-06-19 9 views
2

Je reçois les fichiers css pour réduire et compresser de QueryString["path"] tout fonctionne correctement pour mes propres fichiers CSS comme main.css. Mais quand j'essaye d'accéder aux dossiers de Webresource je reçois une erreur 500. Le paramètre qui vient après le webresource.axd est sensible à la casse et je le reçois de QueryString["path"] en minuscules.Comment obtenir WebResource.axd querystring dans le bon cas?

C'est ce que je reçois de QueryString["path"]:

http://localhost/test/webresource.axd?d=-phgrn6r6zgehvbi697-bxvkl_gidnplxpdeukz5kncgr9hvnfvttpgykwyw05cda-nymtz9od_bbww3ynzxha2&t=633789305460522066 

Le lien ci-dessus génère une erreur: CryptographicException: Rembourrage est invalide et ne peut pas être supprimé.

C'est ce que l'apparence de lien correct comme:

http://localhost/test/WebResource.axd?d=-pHGRn6r6ZGehvBI697-BxVKl_GIdNPlxPdEUKZ5KNcGR9hvnfVtTpgyKwYw05cDa-NymTz9OD_bBwW3ynZXhA2&t=633789305460522066 

La seule différence est dans le cas. CryptographicException semble être commun, mais même la configuration de machineKey n'a pas résolu le problème. Un indice sur comment puis-je obtenir le webresource.axd dans le cas d'origine?

EDIT

code

a été demandé:

public void ProcessRequest(HttpContext context) { 
    Control c = new Control(); 
    string root = context.Request.Url.GetLeftPart(UriPartial.Authority); 
    string path = context.Request.QueryString["path"]; 
    string content = string.Empty; 

    if (!string.IsNullOrEmpty(path)) { 
     if (context.Cache[path] == null) { 
      List<string> dependencies = new List<string>(); 
      string[] styles = path.Split(new string[] { "," }, StringSplitOptions.RemoveEmptyEntries); 
      foreach (string style in styles) { 
       content += RetrieveStyle(root + c.ResolveUrl(style)) + Environment.NewLine; 
       dependencies.Add(context.Server.MapPath(style)); 
      } 
      content = StripWhitespace(content); 
      context.Cache.Insert(path, content, new CacheDependency(dependencies.ToArray()), Cache.NoAbsoluteExpiration, new TimeSpan(DAYS_IN_CACHE, 0, 0, 0)); 
     } 
    } 
} 

Il plante dans RetreiveStyle quand je l'appelle:

using (HttpWebResponse response = (HttpWebResponse)request.GetResponse()) 
+2

Pouvez-vous fournir le code que vous utilisez pour obtenir la ressource Web en premier lieu? –

Répondre

1

Le coupable ressemble le code qui génère le « chemin » querystring csv ou du matériel ou un filtre entre cette source et votre gestionnaire. Si la source de la requête du gestionnaire est un navigateur, à quoi ressemble l'URL du gestionnaire via la source de vue ou le firebug? Est-ce minuscule déjà? À partir de là, avez-vous des modules enregistrés dans votre pipeline IIS?

0

Je n'ai pas de réponse mais nous avons rencontré un problème similaire et j'ai quelques petites choses à ajouter, ce qui pourrait aider à identifier le problème. Alors, voilà:

Nous avons un iHTTPHandler (appelons-le Login.ashx) qui accepte une requête GET, qui contient un jeton au format base64. Le jeton est ensuite déchiffré à l'aide de l'algorithme de Rijndael.

Ce processus fonctionne la plupart du temps, cependant, au cours du mois dernier, plusieurs demandes ont échoué en raison de System.Security.Cryptography.CryptographicException: le remplissage n'est pas valide et ne peut pas être supprimé. erreur. Cette erreur est survenue dans notre cas lorsqu'un jeton (chaîne base64) est en minuscule et ne peut pas être déchiffré. Après avoir parcouru les journaux et les enregistrements d'activité, je peux voir qu'un utilisateur particulier tentera de venir à notre côté via Login.ashx et la demande échouera en raison de l'erreur en question. L'ensemble de la chaîne de requête de la requête (il n'y a pas que le jeton), y compris les noms et les valeurs, est en minuscules. Ensuite, le même utilisateur tentera un login quelques minutes plus tard et pourra entrer car la chaîne de requête n'a pas été transformée en minuscules. Donc, j'ai le sentiment que le problème pourrait être lié au navigateur. Je ne suis pas sûr si proxy pourrait affecter ceci.

Informations supplémentaires: Aucune information de navigateur n'est capturée dans les variables du serveur. les variables ALL_HTTP et ALL_RAW ont presque pas de données:

  • ALL_HTTP HTTP_CACHE_CONTROL: no-cache HTTP_HOST: notre nom du serveur
  • ALL_RAW Cache-Control: no-cache hôte: notre nom du serveur

Il n'y a pas non plus de HTTP_REFFERER.

J'ai essayé de reproduire ce problème avec différents navigateurs (Safari3, Chrome1, Opera9.2, IE6,7,8, Firefox3) sans aucune chance.

Nous avons une ferme Web avec 10 serveurs configurés de manière identique (au moins je l'espère qu'ils sont)

je vais ajouter plus d'informations si je reçois des progrès.