Windows Serverクライアントのアップロードを簡素化するためのIIS設定の調整

多くのWebサイトでは、Webブラウザを介して直接コンテンツをアップロードできますが、この方法ではユーザーとリモートサーバー間の対話性が失われます。相互作用はそれほど簡単ではなくなりました。まず第一に、アップロードプロセスの間にフィードバックは基本的にありません、そして時々長い待ち時間の後に得られる唯一のフィードバックは迷惑なエラーです。それでも、ファイルをアップロードするためにブラウザを使用することは、依然として広く受け入れられているファイル転送方法です。ユーザーはファイル転送プロトコル（FTP）ツールの面倒な使用よりも単純さを好むため。この方法は広く受け入れられていますが、うまくいかないことを保証するものではありません。確認されたMicrosoft IIS問題は48Kより大きいアップロードファイルを処理するときタイムアウトエラーが発生することです。これはアップロードの失敗に過ぎない場合もありますが、それ以外の場合にはブラウザは常にデータを再送信しようとする無限ループに入ることになります。ブラウザに関しては、この特定の状況に対する標準的な応答はありません。この原因は、IISがASPのようなアプリケーションを使用してクライアントデータのアップロードを処理するためです。クライアントがデータのコミットを開始すると、IISは最初の48Kのデータをバッファに読み込み、それを処理のためにアプリケーションに渡します。この48Kを超えるデータは、通常Request.BinaryRead（Request.TotalBytes）のようなコマンドを通じてアプリケーションが転送を要求するまで待機状態になります。アプリケーションが要求しない場合、データは接続を待っています。これは一般的な413エラーです。要求エンティティが大きすぎます。一般に、上記の規則に従って適切にコーディングすることでそのような問題を回避できますが、場合によっては特定のプロパティ設定を使用する必要があります。たとえば、いずれかのサイトのアップロードがサードパーティのISAPIエクステンションによって処理されている場合は、この慣例には従わず、48Kの制限を克服するためにいくつかの調整が必要です。この制限は静的ではなく、UploadReadAheadSizeというIISメタデータ属性によって定義されます。デフォルトは49152Kで、最大値は4GBに設定できます。必要に応じて、別のサイトを設定したり、IISサービス全体を設定したりできます。設定する必要があるのはこれだけではありません。大量のデータのアップロードを許可するには、maxRequestLength（IIS 6の場合）またはmaxAllowedContentLength（IIS 7以降の場合）属性値を変更する必要があります。ただし、既定値は大きくなります。場合によっては、UploadReadAheadSizeの値をゼロに設定すると便利です。これにより、IISは送信されたコンテンツをISAPI拡張アプリケーションに直接ストリーミングして要求を処理します。これはこの問題を解決することを試みる価値がある最初の方法であるかもしれませんがまたまた（先読みバッファを処理しないで）IISアプリケーションをシャットダウンすることの可能な副作用に気づくべきです。最後に、UploadReadAheadSizeの値を大きくすると攻撃を受ける可能性があることに注意してください。この値が高く設定されていて、誰かがファイルをアップロードして帯域幅を消費することによってあなたのシステムを攻撃しようとする場合、それらは簡単に手に入るでしょう。攻撃を回避するには、ユーザーの実際の使用方法を反映した方法を使用し、可能な限り認証を使用するようにして、アップロード者の身元が信頼できるものであることを確認します。