サーバーを単純化するには？設定は、あなたに役立ちます

Windows Serverは、信頼性が高く、使いやすく、拡張性があり、安全で、信頼性の高いプラットフォームです。また、その操作の容易さのために、ファイルをアップロードするためにブラウザを使用することはまだ広く受け入れられているファイル転送方法です。この方法は広く受け入れられていますが、うまくいかないことを保証するものではありません。確認されている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の値を大きくすると攻撃を受ける可能性があります。この値が高く設定されていて、ファイルをアップロードして帯域幅を消費してシステムを攻撃しようとする人は、簡単に入手できます。攻撃を回避するには、ユーザーの実際の使用方法を反映した方法を使用し、可能な限り認証を使用するようにして、アップロード者の身元が信頼できるものであることを確認します。