問題タブ [dotnet-httpclient]

.Net 4.0のimで、HttpClientを使用しようとしています。4.0ではサポートされなくなったが、引き続き使用できるという記事をいくつか読みました。アセンブリを含めましたSystem.Net.Http;が、必要なパラメータをに提供できませんHttpClient。どうすればこれを修正できるでしょうか？

エラーが発生している場所を太字で示しています。

NuGetで利用できるHttpClientを使用しています。

これは私が始めたコードです：

問題：

1. RSS.FeedDataContract/DataMember属性で明示的に定義して装飾する必要がありました。RSSクラスを組み込む必要があるようです。そうですか？（たぶん私はそれについて知らないだけです）

2. これは、RSSフィードの処理命令について不平を言う例外で失敗します。それは実際には私が気にしないスタイルシートです。データが欲しいだけです。

例外は次のとおりです。

例外：System.AggregateException：1つ以上のエラーが発生しました。---> System.InvalidOperationException：XMLドキュメント（1、2）にエラーがあります。---> System.Xml.XmlException：処理命令（XML宣言以外）およびDTDはサポートされていません。行1、位置2。

フィードは次のようになります。

これを行うためのより良い方法に関するヒントはありますか？HttpClientを使用する!!

ドキュメントが少し薄いことがわかりました。

.NET 4.5 HttpClientを使用してWebサイトにログインし、Cookieを受信しようとしています。試してみる直前に中断してCookieContainerを確認しましたが、Cookieが含まれていません。ただし、応答は200ステータスを返します。

これが機能しない理由がわかりません。.NET4スタイルを試してみると問題なく動作します。

POST 要求の場合、text/html形式の応答が返され、応答本文には以下の情報が含まれていました。

oauth_token=XXXXXXXXXXXXXXXXXXXXXXXXX&oauth_token_secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&oauth_callback_confirmed=true

私はこのリクエストを実行し、 asSystem.Net.Http.HttpClientで応答を読み取ることができると思いましたが、デフォルトでapplication/x-www-form-urlencoded形式のみをサポートしていることが判明しました。そのため、次のコードでこれを回避しました。FormUrlEncodedMediaTypeFormatterFormDataCollectionFormUrlEncodedMediaTypeFormatter

ここでの質問は次のとおりです。

応答プロバイダー (この場合は Twitter) は、この応答をtext/htmlとして送信することで間違っていますか、それともデフォルトでtext/htmlタイプをFormUrlEncodedMediaTypeFormatterサポートする必要がありますか?

私は現在DelegatingHandler、署名の検証などのために、送信前に要求を処理するためにいくつかの委任ハンドラー（から派生したクラス）を使用しています。すべての呼び出しで署名の検証を複製する必要がないため、これはすべて非常に便利です（例えば）。

同じWebリクエストからの応答にも同じ原則を使用したいと思います。応答のDelegatingHandlerに似たものはありますか？ある意味で、メソッドに戻る前に応答をキャッチする方法はありますか？

追加情報：私はを使用してWebAPIを呼び出していますHttpClient.PutAsync(...)

Web サービスにリクエストを送信する前に、HttpClient に http ヘッダーを追加する必要があります。(将来のすべてのリクエストに対する HttpClient ではなく) 個々のリクエストに対してそれを行うにはどうすればよいですか? これが可能かどうかはわかりません。

WebAPI の HttpResponseMessage / HttpRequestMessage 型で実際に送受信される HTTP ヘッダーの生のリストを視覚的に確認することは非常に有益です。つまり、各ヘッダーが新しい行にあり、生成または受信されたものとまったく同じ、単純な古い文字列です。

しかし残念なことに、これらのタイプのいずれも、実際に何が生成されるかを確認できるようには見えません。代わりに、プロパティがあちこちに散らばっています。生の HttpResponseMessage / HttpRequestMessage 型自体の一部、response/request.Content.Headers の一部 (この 2 つは繰り返されません。後者は、プロパティとしてまだカバーされていないもの、通常はカスタム ヘッダー用です)、...そしておそらく Cookieどこかに独自のヘッダーの隠し場所があります。また、これらのヘッダー コレクションのリストを視覚的に確認するのも面倒です。つまり、そのようなコレクションごとに一連のコードを反復処理することになり、さらに混乱します。

しかし、実際の応答/送受信されるリクエストでは、そのような区分はなく、すべての Http ヘッダーを簡単に確認できます。それで、私はどこかでそれを見逃していますか？これらのどこかに、生のヘッダー文字列を単に返すシンプルで直感的なプロパティが実際にありますか? 確かに、応答はすでにヘッダーを受け取り、それらを解析しただけです...その生の文字列はどこかに隠されていますか?

(ところで、私は Fiddler について知っています...そしてそれは完全に満足のいくものではありません。Http ヘッダーの低レベルの混乱に対処しなければならない場合、私が使用しているプログラム型でそれらを表示できることは理にかなっていますしかし、さらに悪いことに、(Win8 上で) Fiddler を使用して localhost を動作させることはまだできません。 )

HttpClientMVC 4 Web API を呼び出すために使用しています。私の Web API 呼び出しでは、ドメイン オブジェクトが返されます。何か問題が発生した場合はHttpResponseException、カスタマイズされたメッセージとともに がサーバーにスローされます。

IE F12 を使用して、応答本文でカスタマイズされたエラー メッセージを確認できます。ただし、を使用して呼び出すとHttpClient、カスタマイズされたエラー メッセージは表示されず、http コードのみが表示されます。「ReasonPhrase」は、404 の場合は常に「見つかりません」、500 コードの場合は「Internal Server Error」です。

何か案は？通常の戻り値の型をドメイン オブジェクトのままにして、Web API からカスタム エラー メッセージを返すにはどうすればよいですか?

[Authorize] 属性を追加した Web API があります。これは、以前に行った単体テストが承認されていないために失敗したことを意味します。以下は、基本的なテストと初期化メソッドのサンプルです。

私が疑問に思っているのは、テストをログインさせて認証フィルターを通過させる方法があるかどうか、または HttpClient 要求と共に ASPXAUTH Cookie として渡す方法があるかどうかです。または、私が考えていなかった承認を渡す別の方法はありますか?

私が試したものは何も機能していないようで、どこでも役立つ情報を見つけるのに苦労しています.

前もって感謝します。

On the server I'm forcing compression with a custom message handler. The handler checks the Accept-Encoding header and if it is supported (e.g. GZip) will swap out the HttpResponseMessage.Content with an instance of CompressedContent. This simply compresses the original content like so:

On the client, we can achieve the decompression by checking the Content-Encoding header and using another HttpContent type to perform the decompression:

The part I am unsure of is whether we should be using a custom HttpContent type to do the decompression. On the server it makes sense to do this since we don't really have other way of touching the response stream. On the client however, this could be done by decompressing the standard StreamContent directly or even with a custom HttpClient implementation.