問題タブ [system.net.webexception]

こんにちは、https Web からデータを取得しようとしています (私はファイアウォールやプロキシの背後にいません) が、表示されているメッセージでスローSystem.Net.WebExceptionStatus.SecureChannelFailureし続けるすべての証明書を受け入れても、次のメッセージが表示されます: 要求をキャンセルしました: 安全な SSL/TLS チャネルを作成できません .. . 私はどこでも見たので、あなたたちは私の最後のチャンスです.

前もって感謝します ;）

コマンドを送信し、SSLを介して応答を取得するために、従来のASPに次のスニペットがあります。

次に、このコードを参照として使用して、c＃でリクエストを再実装しました。

問題は、GetRequestStreamを呼び出すと、次のメッセージを含むWebExceptionが発生し続けることです。"The remote server returned an error: (502) Bad Gateway."

最初はSSL証明書の検証と関係があると思いました。だから私はこの行を追加しました：

どこ

そして、私は同じ502エラーを受け取り続けます。何か案は？

誰かが HttpWebResponse と WebException の "StatusCode" プロパティの使用法を明確にするのを手伝ってくれますか?

たとえば、次のように思われます。

a) 例外がない場合、HttpWebResponse には、次の両方を示すいくつかの値を持つ StatusCode があります。 - 成功 (OK、Accepted など) - 失敗 (UseProxy、RequestTimeout など)

b) WebExeption スローがあり、それ自体が再び StatusCode を持つ応答オブジェクトを持っています (これは同じ HttpStatusCode Enumeration に基づいていると思います)。

質問 1 - どの StatusCode が WebException をトリガーするか (および例外内の詳細を取得するか) と、例外なしで返されるが、StatusCode の結果がわかるという点で一貫性はありますか?応答オブジェクト?

質問 2 - 具体的には、ユーザーの応答のカテゴリを区別するために httpWebRequest.GetResponse 呼び出しを処理しようとする疑似コード (または C# コード自体) は何ですか?

• プロキシ設定/プロキシの問題=>ユーザーにプロキシ設定を修正するように指示できます

• 接続の問題/Webサーバーのダウン=>ユーザーはこれを認識しています

• サーバー側のエラー (例: サーバーは存在しますが、リクエストの処理に問題があります - 例: コンテンツが存在しません) => ユーザーはウェブサイト マネージャーで問題を提起できます

• 成功例 (これは単なる OK ではないと思います) => na (成功例)

ありがとう

既存の .NET 2.0 Web サービス内で .NET 2.0 Web サービスを呼び出しています。タイムアウトが発生した場合に Web メソッドからスローされる例外を知りたいです。Web サービスのタイムアウトをデフォルトの 90 秒よりも低い値に設定しており、タイムアウトが発生した場合にビジネス ロジックを追加したいと考えています。

私[System.Net.WebException][1]が見るべき例外はありますか？

デスクトップ アプリケーションにデータを返す Web サービスがあります。私が抱えている問題は、Web サービスが少量のデータを返す場合はすべて正常に動作しますが、データ量が多い場合は次の例外がスローされることです。

System.Net.WebException: 基になる接続が閉じられました: 受信時に予期しないエラーが発生しました。

Web サービスをデバッグしていると、この特定のメソッドが 2 回呼び出されていることがわかります。最初に return ステートメントを実行しても何も起こりませんが、2 回目に実行すると、上記の例外がデスクトップ アプリでスローされます。

以前、stackoverflow で同様の投稿を見つけましたが、問題は解決しませんでした。ここで何が起こっているのか誰か教えてください。

ありがとう！

System.Net.WebException：サーバーがPASVコマンドに応答して、FTP接続が確立されたアドレスとは異なるアドレスを返しました。
System.Net.FtpWebRequest.CheckError（）
at System.Net.FtpWebRequest.SyncRequestCallback（Object obj）
at System.Net.CommandStream.Abort（Exception e）
at System.Net.FtpWebRequest.FinishRequestStage（RequestStage stage）
at System.Net .FtpWebRequest.GetRequestStream（）
at BackupDB.Program.FTPUploadFile（String serverPath、String serverFile、FileInfo LocalFile、NetworkCredential Cred）in D：\ PROJEKTI \ BackupDB \ BackupDB \ Program.cs：line 119

コード：

WebExceptionStatus 列挙の列挙値 Success の目的について少し混乱しています。検索を行ったところ、この列挙が WebException クラスの外部で使用されていることがわかりませんでした。これは私を非常に混乱させます。成功したアクション/状態を示すために例外が使用されるのはなぜですか。何かが足りないのでしょうか、それとも十分に検索しませんでしたか? 将来の機能のために導入されましたか?

誰かがその基本的な目的を知っている場合は、説明を共有していただければ幸いです。

そのため、現在 ePub リーダー アプリケーションに取り組んでおり、System.Xml と XmlDocument を使用して、一連の通常の XML ファイルを読み込んでいます。

ただし、実際の本のテキストを含む XHTML ファイルを開こうとしていますが、それらは XHTML ファイルです。この 2 つの違いはよくわかりませんが、このコードで次のエラーが発生します (同じドキュメントで、同じ XmlDocument 変数と XmlNodeList 変数を使用しています)。

「WebException が処理されませんでした: リモート サーバーがエラーを返しました: (503) サーバーを利用できません」

これはローカル ドキュメントなので、このエラーが発生する理由がわかりません。どんな助けでも大歓迎です。:)

役立つ場合は、ここに完全なソース コードがあります: http://drop.io/epubtest

（私はePubConstructor.ParseDocument()メソッドがひどく面倒であることを知っています。クラスに分割する前に、現時点で機能させようとしています）

私はこれに関するいくつかの決定的なドキュメントを探し回ったが、何も見つけることができなかった.

POST などを実行しHttpWebRequest.GetResponse()た後に生成されるHTTP 応答ステータス コードはどれですか?WebException

具体的には、WebExceptionステータス以外のものを生成します200 OKか? それともWebException、たとえば、400、404、および 500 (議論のために) のみを生成しますか?

HTTP 200 OK私が通信しているサーバーは、エラー状態として戻ってくる以外のことを定義しているので、知りたいです。WebException200 以外の生成を信頼できますか?

私は現在、毎回リターンステータスコードをチェックし、それが200 OK. WebExceptionそうでない場合は、適切なアクションが実行されますが、そのコードと、クリーンアップしたいと考えているa の catch ブロックの間には多くの重複があります。

ドキュメントへの関連リンクは、非常に高く評価されます。

HTTP POST と GET を操作するカスタム Http ハンドラーがあります。プロジェクトを別の隔離されたサーバーで動作させたので、それを本番環境に置く必要があります...

何らかの理由client.UploadFile("", file);で、HTTP POST を強制的に使用する場合

これは何ですか？コードが機能することはわかっています。サーバーが HTTP POST 要求をブロックしている可能性がありますか?

私は追加しようとしました：

ServicePointManager.Expect100Continue = false;

しかし、私はこのコードが以前にどこにあるべきか100％確信が持てませんでしたが、成功していません.WebClientを使用する前だと思います

編集 0 :

私はちょうど次のことを読んだ：

古い実装が存在するため、プロトコルは、クライアントが 417 (Expectation Failed) ステータスまたは 100 (Continue) ステータスを受信せずに「Expect: 100- continue」を送信する可能性があるあいまいな状況を許可します。したがって、クライアントがこのヘッダー フィールドを、100 (Continue) ステータスを確認したことがないオリジン サーバーに (おそらくプロキシ経由で) 送信する場合、クライアントは、リクエスト ボディを送信する前に無期限に待機するべきではありません (SHOULD NOT)。

このリクエストはプロキシ経由で行われていると思いますが、これが問題に関係している可能性があります。

編集1：

この問題は 100-continue にあると信じてください。なぜなら、fiddler を使用してアプリケーションが何を送信しているかを正確に確認すると、次のようになるからですWebClient.UploadFile。

その行を入れたにもかかわらず: ServicePointManager.Expect100Continue = false;using ステートメントの前に。この行は実際には機能しないと思います。