ただそれをしないでください!これらの理由から:-
- サーバーに 2 番目の要求を戻すと、現在のスレッドがブロックされます。これらの要求が多すぎると、アプリケーションがデッドロックします。
CreateHTMLBody
内部では、WinINET http スタックを使用して要求を行います。このスタックは、クライアントのインタラクティブなシナリオで使用することを目的としています。サーバーのシナリオでは、スレッドセーフではありません。
- すべてのセッション コンテキストが失われるため、(発見しているように) 何かがより困難になったり、安全性が低下したりする可能性があります。さらに、不要なセッションの負荷が発生する可能性があります。
その真CreateHTMLBody
は非常に便利ですが、肥大化した電子メールを作成することもできます. サーバーの状況では、この魅力的な方法を使用するのではなく、コードを使用して電子メールを作成する必要があります.
編集
Jimbo は、CreateHTMLBody だけでなく、より一般的なシナリオを念頭に置いているようです。一般的なシナリオは、(消費者が制御できない) コンポーネントが ASP ページ (これを「クライアント ページ」と呼びます) で使用され、別の ASP ページ (おそらく WinINET を介して) に後続の要求を行うというものです。これを「サービスページ」と呼びます)。コンポーネントの使用に関して「クライアント ページ」が制御できる唯一のものは、それに提供される URL であるという前提があります。
上記の問題を回避または軽減するためのいくつかのアプローチを次に示します。
ロックの問題の処理:「クライアント ページ」と「サービス ページ」を別の ASP アプリケーションに配置すると、ロックの問題を回避できます。私の提案は、「クライアントページ」をアプリケーションの残りの部分とは別のアプリケーションに配置し、この新しいアプリケーションをメインアプリケーションのサブフォルダーに配置することです。
WinINETの問題への対処: 新しいアプリケーションを独自のアプリケーション プールに配置します。安全でない方法で WinINET を使用して問題が発生した場合でも、メインのアプリケーション プロセスには影響しません。実際、それを独自のプロセスに配置すると、このような問題を回避するのに役立つ場合があります。(ここでの保証はありませんが、WinINET の問題を完全に回避するための最良の方法です)。
セキュリティの制御:「クライアント ページ」からの要求のみを受け入れるように「サービス ページ」を構成します。これを行う方法はおそらくいくつかありますが、最も簡単な方法は、IP ベースのセキュリティを有効にすることです。「サービス ページ」へのリクエストは、特定の IP または少なくとも限られた IP アドレスのセットからのみ送信される必要があります。
認証 の処理: メイン アプリケーションのログオン時に、一意の値を含む揮発性 Cookie を作成します。「クライアント ページ」はブラウザによってメイン アプリケーションのサブフォルダとして認識されるため、この Cookie を受け取ります。「クライアント ページ」は、この Cookie を使用して、リクエストの信頼性を確認したり、コンポーネントの使用時に URL に渡したりできます。
大量のセッション作成の抑制:Session.Abandon
操作が完了する前に「サービス ページ」を呼び出します。