3

状況

簡単そうに見えます: IIS 7 で実行されているサービスがあります。クライアントがデータ (application/json) をポストし、それを受け入れる前にデータを検証します。

私がそれを受け入れない場合は、406 と ~同じ~ データを body として返したかった (潜在的に変更/修正された) [1]。残念ながら、これは無効な json とも呼ばれる切り捨てられた応答本文につながります。

まず、エラーのパススルーを有効にします。そうしないと、IIS が巧妙になろうとするためです。

<httpErrors errorMode="Detailed" existingResponse="PassThrough">
</httpErrors>

私のコードの関連部分は、これと道徳的に同等のことを行います:

HttpResponseBase response = context.HttpContext.Response;

response.StatusCode = StatusCode;
response.StatusDescription = StatusDescription;

if (!string.IsNullOrEmpty(ContentType))
    response.ContentType = ContentType;
else
    response.ContentType = "application/json";

if (ContentEncoding != null)
    response.ContentEncoding = ContentEncoding;

using (var sw = new StreamWriter(response.OutputStream))
{
    sw.Write(JsonConvert.SerializeObject(Data));
}

クライアント側では、現在ナイーブを行っています（jsonの切り捨ての問題を見つけるため）

var response = myRestClient.Execute(myRestRequest);

問題

応答がステータス コード 200 を返す場合、これを取得します

response.ContentLength == 69345
response.RawBytes.Length == 69345

返されたステータス コード (私の場合は 406 に)だけを変更し、まったく同じデータを返すと、次のように表示されます。

response.ContentLength == 69345
response.RawBytes.Length == 65536 // <--- Not! Good!

さて、65536 はあまりにも魔法の数であり、宇宙線の一致または非常に再現可能な結果ではありません。unsigned short の長さを超えた場合にデータを捨てて、賢くしようとしているのは誰ですか? 今すぐ RestSharp コードベースに飛び込んでみますが、IIS が再びだまされているのではないかと本当に疑っています..

1: これが悪い考えだとしたら、その理由を詳しく教えてください。

4

1 に答える 1