14

元の質問:

WebResource.axd の URL 生成で奇妙なエラーが発生します。(かなり一般的な「WebRsource.axd パディングが無効であり、削除できない」問題とは関係がないようです)。

作成時にスクリプト参照を WebResource.axd に追加する ASP.NET Web ページがあります。

この場合、WebResource.axd リンクが特定のポイントを過ぎると時々ガベージになり、javascript のように見えるものに置き換えられることがわかります。さらに悪いことに、URL 生成の失敗は一貫していないようです。

この場合、リンクは次のようになります (通常は次のようになります)。

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

すべて順調です。ただし、ユーザーからログに記録されたエラーを取得しています...そして、ユーザーがアクセスしようとしている URL は次のようになります (あるケースでは):

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

[そのリンクからの残りのエンコードされた JavaScript は無関係として削除されました]

見知らぬ人ですが、ページをリロードしようとしているように見える同じユーザーから、これらのいくつかを立て続けに取得しました...それぞれの URL はわずかに異なります。

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

ガベージがエンコードされた JavaScript である場合もあります。URL の一部を見たことがあります...完全に空のパラメータ文字列...明らかなパターンは見当たりません。

余談ですが、関連する場合は、この WebResource が、特定の機能がページに含まれているときに .NET によって自動的に含まれるストック WebResource 以外のものであるとは思わないことに注意してください...この場合、フィールドバリデーター。実際の WebResource.axd の内容を見ると、一般的な .NET イベントを処理するように設計されているように見える非常に標準的な Javascript 関数のセットが明らかになります。私たちが作成したものではありません。

誰もこのようなものを見たことがありますか？（または、なぜこれが起こっているのかを理解し、それを排除する方法を考え出した人はいますか？）

EDIT 0:いくつかの追加情報:

項目 1: 1 つの回答に応じて、doctype が xhtml トランジショナルであるため、スクリプトが CDATA タグで囲まれていることを確認しました。

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

残念ながら、私たちは大きな期待を寄せていましたが、問題は解決していないようです. これはブラウザーとして IE 8 を使用する場合により頻繁に見られます。これは、これがブラウザー関連であるという考えにある程度の信憑性を与えるでしょう...おそらくブラウザーがストリームを解析する方法です...しかし、なぜ微妙に異なる応答が得られるのでしょうか?その後の試みで私を困惑させます。

項目 2: 省略されたセクションは、かなり規則的なサイズのブロックのように見えます。誰かが 1k または 4k のブロックが欠落しているのを見たと報告しましたが、私 (これまでのところ... これまでに 2 つのケースしか見ていません) は同意します (私の場合は両方とも 4096 バイトのデータが欠落していました)。

4

7 に答える 7

7

この投稿によると：

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

この問題は、doctype が指定されていない場合にブラウザーがページを異なる方法でレンダリングすることが原因であると思われます。

これは、この件に関して私が見つけた別の興味深い投稿ですが、まだ解決策ではありません:

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

上記のページでは、コメントに可能な解決策として「Response.Cache.SetNoStore()」があります。次にこれを試して、役立つかどうかを確認します。

于 2009-02-04T15:03:11.583 に答える
5

Microsoft は、この問題に次のように対応しています。

注: Internet Explorer 8 のバグです。Internet Explorer チームは、この問題を調査しています。

-=Impact=- これまでのところ、この問題は Web アプリケーションでのエンド ユーザーのエクスペリエンスに影響を与えていないと考えています。唯一の悪影響は、JavaScript の投機的ダウンロード エンジンによって送信される偽の/不正な形式の要求です。パーサーがスクリプトを実際に必要とする場合、スクリプトは適切にダウンロードされ、その時点で使用されます。

-=状況=- spurious-request は、特定のタイミング状況でのみ、CHARSET ディレクティブを持つ Content-Type を含む META HTTP-EQUIV タグがドキュメントに表示された場合にのみ、JavaScript SRC URL が 4096 番目にまたがる場合にのみ発生するようです。 HTTP 応答本文のバイト。

-=回避策=- したがって、ページ内で指定するのではなく、HTTP Content-Type ヘッダーを使用してページの CHARSET を宣言することで、この問題を軽減できると現在考えています。

だから、置くのではなく

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

代わりに、head タグで次の HTTP 応答ヘッダーを送信します。

コンテンツ タイプ: テキスト/html; 文字セット=utf-8

HTTP ヘッダーで文字セットを指定すると、すべてのブラウザでパフォーマンスが向上することに注意してください。これは、ブラウザのパーサーが文字セット宣言に遭遇したときに解析を最初からやり直す必要がないためです。さらに、HTTP ヘッダーを使用すると、特定の XSS 攻撃ベクトルを軽減するのに役立ちます。

注: META HTTP-EQUIV がページにない場合でも、この問題が発生するという報告があります。さらに調査が行われたら、このコメントを更新します。Microsoft によって 2009 年 6 月 30 日午後 12 時 25 分に投稿されました。

于 2009-07-06T13:48:55.127 に答える
2

私は ASP.NET チームの一員です。この問題の調査に協力してくださるお客様を探しています。自分のページをリクエストしてログを確認することで問題を確実に再現でき、サポート グループと協力してくれる人がいる場合は、返信するか、ダイレクト メッセージを送ってください。ありがとう！

于 2009-06-05T19:15:47.737 に答える
1

ユーザーに送信される前に、レンダリングされた HTML を変更する Web 構成に登録されている HttpHandlers またはモジュールを取得しましたか?

多くの場合、次のような場合があります。

  • JS と CSS の最小化
  • HTML が有効であることを確認する

一見の価値があるかもしれません。

于 2009-04-24T08:25:32.797 に答える
1

どのバージョンの .NET に対してコンパイルしていますか? 古いバージョンまたは新しいバージョン用にビルドするようにビルドを変更するとどうなりますか? （これでうまくいくかどうかはわかりませんが、試してみる価値はあります）

まだ発生している場合は、 Microsoft Connectにバグを投稿する必要があると思います。彼らはすぐに戻ってくるはずです。

于 2009-04-24T07:02:54.303 に答える
0

これは古い投稿です...しかし、Google検索で出くわし、これを思い出しました...

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

関連していたのではないでしょうか？

于 2010-09-27T00:31:42.073 に答える
0

これは最終的に Microsoft によって修正されました。

http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

于 2013-02-01T21:47:26.277 に答える