フォーム送信、出会いとのHttpClientとのトラブル

問題

インターフェースはフォームを通じて写真や他の識別データをアップロードするために必要とされる部分にマイクロチャネルの有料の発展における小零細企業。マイクロチャネルインタフェースドキュメント内の支払いはマルチパート/フォームデータの送信要求を必要としていることも示しています。.NETが提供MultipartFormDataContent私たちは、フォームの要求を構築するため、次のコードを持って支援し、タイプ：

var form = new MultipartFormDataContent()
{
    {new StringContent("Value"),"Name},
    {new ByteArrayContent(new byte[]{}/*模拟文件数据*/),"File,"FileName}
}

マイクロチャネルの有料に従い、公式文書を提出した後、困惑、パラメータエラーを求めています。

理由

ポストマンアナログフォームの送信によって、パケットをキャプチャし、C＃コードと比較が送信され、両者は問題を発見しました。

ポストマンオリジナルの提出：

POST http://api.mch.weixin.qq.com/secapi/mch/uploadmedia HTTP/1.1
User-Agent: PostmanRuntime/7.21.0
Accept: */*
Cache-Control: no-cache
Postman-Token: b6800c0f-3f16-4981-b661-e6d16fc1bb1e
Host: api.mch.weixin.qq.com
Content-Type: multipart/form-data; boundary=--------------------------639275760242036520206377
Accept-Encoding: gzip, deflate
Content-Length: 566
Connection: keep-alive

----------------------------639275760242036520206377
Content-Disposition: form-data; name="mch_id"

1565111111
----------------------------639275760242036520206377
Content-Disposition: form-data; name="media_hash"

7215E92A8F3F3D0256484EFFF53A25F6
----------------------------639275760242036520206377
Content-Disposition: form-data; name="sign_type"

HMAC-SHA256
----------------------------639275760242036520206377
Content-Disposition: form-data; name="sign"

A1D8B094FA24BE5531D1AC198DE25550
----------------------------639275760242036520206377--

C＃のコードを提出します：

POST http://api.mch.weixin.qq.com/secapi/mch/uploadmedia HTTP/1.1
Host: api.mch.weixin.qq.com
Content-Type: multipart/form-data; boundary="e9d5712f-7923-4ec5-8bf3-c8d5d3cd3217"
Content-Length: 502

--e9d5712f-7923-4ec5-8bf3-c8d5d3cd3217
Content-Type: text/plain; charset=utf-8
Content-Disposition: form-data; name=mch_id


--e9d5712f-7923-4ec5-8bf3-c8d5d3cd3217
Content-Type: text/plain; charset=utf-8
Content-Disposition: form-data; name=media_hash

33F15BC2D17D6FFBC18FA566EF65722E
--e9d5712f-7923-4ec5-8bf3-c8d5d3cd3217
Content-Type: text/plain; charset=utf-8
Content-Disposition: form-data; name=sign

1E377684F9BD583D2ED26FB367916C0C
--e9d5712f-7923-4ec5-8bf3-c8d5d3cd3217--

1.境界二重引用符

使用しMultipartFormDataContent、外部フォームの送信要求Content-Typeへboundaryと値"の数字。ポストマン、フォームを送信した要求、そのboudary値は二重引用符ではありません。

なぜ、このような差が生じますか？参照この RFC 2046の実現のために、各システム/言語が矛盾によって引き起こされるので、説明するために、ブログを、それがあります。中のためにMultipartFormDataContent行動、二重引用符との境界バックの値が標準である場合。

RFC 2612オリジナル：

2）RFC 2046 [40]は、境界文字列がされることを可能にするが
引用され、いくつかの既存の実装では、引用符で囲まれた境界ハンドル
誤って文字列。

境界効果は、ランダムな文字列が生成され、HTTPプロトコルは、内部コンテンツの複数に分割されています。なぜランダムに生成されますか？これは、区切り文字防ぐため、あなたのコンテンツが事故を起こしたとの内部繰り返しを生成することです。（C＃ののGUIDランダムな文字列としてデフォルトで使用され、コンフィギュレーションであってもよく、MultipartFormDataContent手動でそのコンストラクタを指定することで、時間）

2.、キーと値のペアを形成し、二重引用符値

第二の問題は、彼らの形式のコンテンツであるnameあなたは、時間のコンテンツを追加する必要がありますので、手動で二重引用符を指定する必要があり、値なし、二重引用符のキーと値のペア、。

解きます

二つの問題は、内部の空である、または二重引用符が欠落して追加することが、実際には二重引用符を置き換えるために通話を開始する前に、二重引用符ので、それが必要なだけである引き起こされます。

問題のために、その内部ContentType.Parameters見つけることがLINQ通じ、boundaryキーと値のペアを、あなたは二重引用符の内部を置き換えることができます。

var boundaryValue = form.Headers.ContentType.Parameters.Single(p => p.Name == "boundary");
boundaryValue.Value = boundaryValue.Value.Replace("\"", String.Empty);

コンテンツの内部構造は、手動で二重引用符にその名を与えられた質問2について。

var form = new MultipartFormDataContent
{
    {new StringContent(mchId), "\"mch_id\""},
    {new ByteArrayContent(bytes), "media", $"\"{HttpUtility.UrlEncode(Path.GetFileName(imagePath))}\""},
    {new StringContent(mediaHash), "\"media_hash\""},
    {new StringContent(sign), "sign"}
};

フォーム送信、出会いとのHttpClientとのトラブル

問題

理由

解きます

おすすめ