1

パーソナルサーバーにファイルをアップロードしようとしています。

これまでのところ、問題なく動作する小さなphpページを作成しました。

少し奇妙なことは、送信するHTTPメッセージの本文をすべて生成して（たとえば、最大4 mbに達する）、サーバーにリクエストを送信するという事実です。

次に、サーバーはHTTPチャレンジを要求し、デリゲート接続：didReceiveAuthenticationChallenge：challengeは、適切な資格情報とデータを使用してサーバーに応答します。

しかし、何が起こったのでしょうか。データは2回送信されました！

実際、プログレスバーを追加すると、アプリがデータ（4mb）を送信し、サーバーが認証を要求し、アプリが認証（別の4mb）でデータを再送信することに気付きました。それで、最後に、私は8mbを送りました。それは間違っている。

グーグルして解決策を探し始めましたが、これを修正する方法がわかりません。

ケースシナリオは2つです（私の推測）：

  • セッション全体のレルムを共有します（最小限のHTTPリクエスト、チャレンジ、データの順に）
  • 同期された方法を使用してHTTP接続を実行します（この種のものを処理するのは醜い方法のように思われるため、やりたくないことです）

ありがとうございました

4

2 に答える 2

3

httpプロトコルに欠陥があります。認証チャレンジで応答を取得する前に、すべてのデータを送信する必要があります（資格情報なしでリクエストを送信する場合）。HEADリクエストのように、同じセッションの最初のリクエストとして（前述のように）小さな往復を試してみると、将来のリクエストは同じナンスを共有します。

于 2010-05-13T15:42:21.787 に答える
2

元の要求者に答えるには遅すぎますが、誰か他の人がこれを読んだら間に合います。

TL; DR：RFC 2616のセクション8.2.3は、このような状況で必要な（必要だった）すべての100続行ステータスについて説明しています。セクション10.1.1および14.20もご覧ください。

クライアントは「Expect：100-continue」ヘッダーを使用してリクエストを送信し、本文を送信する前にリクエストを一時停止します。サーバーは、すでに受信したヘッダーを使用して、この要求を受け入れるかどうかを決定します（受信するエンティティ（本体）が大きすぎない場合、ユーザーの資格情報が正しい場合...）。リクエストがサーバーに受け入れられる場合、サーバーは「100続行」ステータスコードで応答し、クライアントは本文を送信し、サーバーはそのリクエストの最終ステータスコードで応答します。逆に、リクエストが受け入れられない場合、サーバーは4xxステータスコードで応答します（提供されたボディサイズが大きすぎる場合は「413Request Entity Too Large」、または「401Unauthorized」+WWW-Authenticate ：ヘッダー）、クライアントは本文を送信しません。

于 2011-03-06T21:50:54.233 に答える