Non Valide Webresource.axd paramètres générés

Question D'Origine:

Nous avons une étrange erreur avec WebResource.axd url génération. (Il ne semble pas être liée à l'assez commun "WebRsource.axd Rembourrage est pas valide et ne peut pas être supprimé").

Nous avons une ASP.NET page web, qui, lorsqu'ils sont créés, ajoute une référence de script à WebResource.axd.

Dans ce cas, nous constatons que les WebResource.axd lien se transforme parfois en des ordures delà d'un certain point, remplacé par ce qui ressemble à du javascript. Pire encore, l'url de génération de l'échec semble être incompatible.

Dans notre cas, le lien doit (et généralement ne ressembler):

/WebResource.axd?d=D-wd7RbHCvSp_p0mHAmE4g2&t=633464867255568315

Tout va bien. Toutefois, nous sommes d'avoir des erreurs enregistrées auprès des utilisateurs...et l'url qu'ils essaient d'accéder ressemble (dans un cas):

/WebResource.axd?d=D-wd7RbHCvS/../../images/icons/Ico_resize.gif')}}function%20ShowFilter_Manufacturer(){var%20div.......

[le reste codé en javascript à partir de ce lien a été supprimé comme inutile]

Inconnu encore, nous avons eu quelques-uns de ces en succession rapide à partir de la même utilisateur, qui était apparemment en train de recharger la page...chaque url légèrement différente.

/WebResource.axd?d=D-wd7RbHCvS<garbage>
/WebResource.axd?d=D-wd7RbHCvSp<garbage>
/WebResource.axd?d=D-wd7RbHCvSp_<garbage>

Dans certains cas, le ramassage des ordures est codé en JavaScript, j'ai vu des parties de l'url...complètement vide chaînes de paramètres...je ne vois pas un modèle évident.

Que d'un côté, devrait-il être pertinent, il convient de noter que je ne crois pas que ce WebResource est rien d'autre qu'un stock WebResource qui est automatiquement inclus .NET lorsque certaines fonctions sont inclus sur une page...dans ce cas, un champ de validateur. En regardant le contenu de la réelle WebResource.axd révèle très standard à chercher ensemble des fonctions Javascript qui semblent conçus pour gérer les génériques .NET événements. Pas tout ce que nous avons créé.

Quelqu'un a vu quelque chose comme cela? (ou mieux, quelqu'un a compris pourquoi ce qui se passait, et trouver un moyen de l'éliminer?)

MODIFIER 0: Quelques informations supplémentaires:

Article 1: En réponse à une réponse, nous avons fait en sorte que nos scripts sont enfermés avec CDATA balises, depuis notre doctype xhtml transitionnel:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Malheureusement, même si on avait de grands espoirs, il ne semble pas avoir résolu le problème. Nous avons remarqué plus d'une fois avec IE 8 comme navigateur, ce qui permettrait de prêter foi à l'idée que c'est liés au navigateur...peut-être la manière dont le navigateur analyse le flux...mais pourquoi on serait subtilement différentes réponses sur les tentatives ultérieures me déroute.

Point 2:
Il s'avère que le omise sections semblent être des blocs de assez régulière de la taille. Quelqu'un a signalé qu'il était de voir 1k ou des blocs de 4k manque, et j'ai (pour l'instant...je n'ai regardé que deux) serait d'accord (les miens étaient tous deux disparus 4096 octets de données).

Mise à jour: Le 4k bug est désormais corrigé par les IE8 mise à jour Cumulative sur 3/30/2010. blogs.msdn.com/ieinternals/archive/2010/04/01/...

OriginalL'auteur |

  1. 7

    selon ce post:

    http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv

    Il semble que le problème est causé par la façon dont les navigateurs rend les pages différemment lorsque le doctype n'est pas spécifié.

    Voici un autre article intéressant que j'ai trouvé sur ce sujet, toujours pas la solution:

    http://blog.aproductofsociety.org/?p=11

    sur la page mentionnée ci-dessus, il a "Réponse.Le Cache.SetNoStore()" comme une solution possible dans les commentaires, je vais essayer de ce côté pour voir si ça aide.

    Saint macaroni! J'avais à peu près renoncé à celui-ci. Je vais aller l'essayer maintenant. Je vais voter jusqu'à maintenant, mais si cela résout le problème, je vais être en souhaitant que je pouvais voter pour celle-ci à plusieurs reprises. Merci, de toute façon.
    Argh. Pas de dés. Je pense que c'est probablement la réponse qui fonctionne pour certaines personnes, mais nous sommes toujours le même problème...(même si je m'attends à la cause sous-jacente peut-être encore la même chose...)
    Oui, nous sommes toujours à avoir ce problème là aussi, c'est quelque chose d'intéressant, j'ai trouvé blog.aproductofsociety.org/?p=11
    Bleh. Eh bien, depuis que je suis rien sur cette mesure, vous pourriez finir vers le haut avec 200 rep par défaut!
    Si vous, iriez-vous à connect.microsoft.com/VisualStudio/feedback/..., et des taux très, de sorte que nous avons une meilleure chance d'obtenir ce problème résolu?

    OriginalL'auteur John Boker

  2. 5

    Microsoft a répondu à cette question:

    Note est un bug dans Internet Explorer 8. L'équipe Internet Explorer a été une enquête sur ce problème.

    -=Impact=- jusqu'à présent, nous croyons que le problème n'a pas d'impact sur l'expérience utilisateur de l'application web; le seul effet négatif est le faux/mal formé demandes envoyées par le JavaScript spéculative-moteur de téléchargement. Lorsque le script est en fait nécessaire par l'analyseur, il va être téléchargé et utilisé à l'époque.

    -=Circonstances,= - Le faux-demande semble se produire que dans certaines calendrier situations, que lorsqu'un META HTTP-EQUIV balise contenant un Type de Contenu avec un jeu de caractères de la directive apparaît dans le document, et seulement lorsqu'un JavaScript SRC URL enjambe le 4096th octet du corps de la réponse HTTP.

    -=Solution=- Donc, actuellement, nous pensons que ce problème peut être atténué en déclarant le CHARSET de la page à l'aide de HTTP en-tête Content-Type, plutôt que de spécifier dans la page.

    Donc, plutôt que de mettre

    [META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8"]

    Dans votre balise head, au lieu de cela, envoyez-tête de réponse HTTP:

    Content-Type: text/html; charset=utf-8

    Noter que la spécification du jeu de caractères dans l'entête HTTP résultats dans l'amélioration des performances dans tous les navigateurs, parce que le navigateur analyseurs n'a pas besoin de redémarrer l'analyse depuis le début lors de la rencontre de la déclaration du jeu de caractères. En outre, en utilisant l'en-tête HTTP contribue à atténuer certains vecteurs d'attaque XSS.

    REMARQUE: Il a été signalé que ce problème se produit toujours lorsque le META HTTP-EQUIV n'est pas sur la page. Nous mettrons à jour ce commentaire lorsque nous aurons plus d'enquête.
    Posté par Microsoft sur 6/30/2009 à 12:25 PM

    OriginalL'auteur

  3. 2

    Je suis de la ASP.NET l'équipe nous recherchons pour un client prêt à travailler avec nous sur des recherches sur cette question. Si quelqu'un est capable de reproduire de manière fiable le problème en demandant à leurs propres pages et de vérifier les journaux, et est prêt à travailler avec notre groupe de soutien, s'il vous plaît répondre ou de m'envoyer un message direct. Merci!

    Ceci a été écrit il y a quelques temps, et après beaucoup plus de l'enquête et à corroborer avec d'autres personnes ayant le même problème, il ressemble à ce qui est, en fait, un IE 8.0 question. Pourtant, je pense que je parle pour tout le monde quand nous disons que nous aimerions quelqu'un directement impliqués à donner à ce look. Est-il une bonne façon de porter cette question à l'attention de l'IE 8 de l'équipe? Microsoft se Connecter au forum pour IE semble être fermé, et pas d'autres évident avenues viennent à l'esprit.
    Oui, un bon moyen est de me contacter si vous êtes en mesure de fournir toute repro. Le fait que je suis de la ASP.NET l'équipe ne veut pas dire la IE8 équipe n'est pas impliqué -- nous sommes en utilisant toutes les ressources que nous pouvons comprendre, y compris IE des gens. Ce connect bug est aussi un bon endroit pour ajouter de l'information: connect.microsoft.com/VisualStudio/feedback/...

    OriginalL'auteur InfinitiesLoop

  4. 1

    Quelle version de .NET vous compilation contre? Qu'advient-il si vous changez de construire de construire pour une ancienne ou une version plus récente? (pas sûr si cela ferait n'importe quoi mais il vaut la peine d'essayer)

    Si il est encore arrive, je pense que vous devez poster un bug à ce sujet sur Microsoft Connect. Ils devraient revenir vers vous très vite.

    Modification de l' .NET version: malheureusement, ce n'est pas une option pour nous... Microsoft Connect: je vais vous donner un coup de feu!
    J'ai reçu une réponse qu'ils (Microsoft) sont à la recherche dans la question...j'espère qu'ils ne seront pas simplement de dire "nous ne pouvons pas reproduire" et le fermer.
    Cool. J'ai voté pour elle aussi. Bonne chance 🙂

    OriginalL'auteur Mladen Mihajlovic

  5. 1

    Avez-vous de HttpHandlers ou les Modules qui sont enregistrés dans le site web de config à modifier le rendu HTML avant d'être envoyé à l'utilisateur?

    Ceux-ci peuvent souvent être:

    • Minifiying JS et CSS
    • Assurer HTML est valide

    Peut-être en valeur un regard.

    Bonne réflexion, mais je suis sûr à 95% que la réponse est non. Mais je vais certainement demander autour pour vérifier.

    OriginalL'auteur Zhaph - Ben Duguid

  6. 0

    C'est un vieux post... mais je suis venu à travers à travers une recherche sur google et m'a rappelé de cette...

    http://www.troyhunt.com/2010/09/fear-uncertainty-and-and-padding-oracle.html

    Pourrait-il avoir été liée?

    OriginalL'auteur