2012-01-09 12 views
3

HttpWebRequest/HttpWebResponseオブジェクトを使用してWebサイトにリクエストしています。HttpWebResponse.GetResponse()fiddlerは、「レスポンスヘッダーの解析に失敗しました」と言います。

私はウェブサイトにいくつかの呼び出しを成功させています。同じ動的ページへの呼び出しがすべて失敗しています。デバッガで

私は「内部サーバーエラー500」を取得していますシオマネキも500応答を示し、含まれています。私はすべての六角を削除し、ページを見てきました

[Fiddler] Response Header parsing failed. 
This can be caused by an illegal HTTP response earlier on this reused server socket--  for instance, a HTTP/304 response which illegally contains a body. 
Response Data: 
<plaintext> 
0D 0A 3C 21 44 4F 43 54 59 50 45 20 48 54 4D 4C 20 50 55 42 4C 49 43 20 ..<!DOCTYPE  HTML PUBLIC 
22 2D 2F 2F 57 33 43 2F 2F 44 54 44 20 48 54 4D 4C 20 34 2E 30 20 54 72 "-//W3C//DTD HTML 4.0 Tr 
61 6E 73 69 74 69 6F 6E 61 6C 2F 2F 45 4E 22 3E 0D 0A 3C 48 54 4D 4C 3E ansitional//EN">..<HTML> 
0D 0A 09 3C 48 45 41 44 3E 0D 0A 09 09 3C 74 69 74 6C 65 3E 56 69 65 77 ...<HEAD>....<title>View 

と私は期待するものです何らかの理由でサーバが500を報告しており、HttpWebRequestオブジェクトがこの例外をスローします。

私はこの問題のために他のすべての "修正"を試みましたが、何もしませんでした。それはサーバーから送信された不正なデータだけかもしれませんが、HttpWebRequestよりも低いレベルのオブジェクトがあります。これは、動作するピタではありませんか?

EDIT:上記の例では、16進数/全体のhtmlブロックは含まれていませんでした。
EDIT:シオマネキをオフにする私は、デバッガでこれを取得

EDIT:だから、私が見たものからHttpWebResponseのオブジェクトはそれに応じて行動しています。サーバーはちょうど薄れており、いつも異なるHTTPステータスコードで同じ正確なデータを返します。クイックフィックスのために、私はちょうどtry/catchで各呼び出しをラップし、正確に同じ呼び出しを再試行するcatchブロックでラップしました。これまでのところ、HttpWebResponseオブジェクトではなく、サイトフォールトであることを大きく証明しています。

The server committed a protocol violation. Section=ResponseStatusLine 
+1

あなたがヒットしようとしているウェブサイトを制御することがありますか? –

+0

@ M.Babcock私はしません。これまでのところ、私は500のレスポンスからHTMLを取り除いて解析することができるように見えますが、それは悪臭を放つでしょう! – user1231231412

+0

@Amadanこれはwinformsアプリケーションです。 – user1231231412

答えて

0

ヘイジョン、

ですフィドラーなしの同じ結果? (画面に例外を表示するだけです)。私はデバッガの誤動作で時には問題を抱えていました。

サーバーが断続的なエラーを返していて、そのサーバーを制御できない場合は、あまりお世話になりません。メッセージは304の標準であることは明らかですが、レスポンスはボディを持つべきではありませんが、サーバは何でもできます。

参照W3C:クライアントが条件付きGETリクエストを実行し、アクセスが許可され ですが、ドキュメントが変更されていないhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

場合、サーバーはこのステータスコードで応答する必要があります。 304応答はメッセージ本体を含んではならない(MUST NOT)。したがって、ヘッダーフィールドの後の最初の空行で常に終了する。

HttpWebRequestに関しては、何の問題もなく、HTTP通信を処理できないケースは一度も聞いたことがありません。しかし、場合は、あなたはナットをして、パケットを自分で処理する、Googleはソケットを使用して独自のHttpWebRequestを構築する方法です。

このプロジェクトはスタートすることができます http://www.codeproject.com/Articles/13486/A-Simple-Crawler-Using-C-Sockets

+0

リンクをありがとう、いいプロジェクトのようです。 – user1231231412

1

HTTP 304応答は、ページの内容が(彼らはおそらくキャッシュを使用している)あなたがページをヒット前回変更されていないことを意味します。頻繁にページにヒットしたり、これに遭遇したときにレスポンスをキャッシュしてください。

EDIT

サーバがデータを含む無効な304応答を送信しています。これはHTTP仕様に違反し、HttpWebResponse/Fiddlerはそれを有効に500に変換します。

EDIT

あなたは、あなたのapp.configに設定次を使用している場合HttpWebRequest/HttpWebResponseを使用して維持することができる場合があります。

<configuration> 
    <system.net> 
     <settings> 
      <httpWebRequest useUnsafeHeaderParsing="true" /> 
     </settings> 
    </system.net> 
</configuration> 
+0

最初のページでは、ダウンロードしているファイルへのリンクをいくつか集めています。後続のサイトへのヒットは、同じ「ダウンロード」URLにありますが、異なるクエリーストリングのパラメータを使用しています。私はそれがキャッシングを妨げるだろうと思うだろうが、それは特定の構成のためだけかもしれない。 – user1231231412

+0

キャッシュのシステムがどれほど洗練されているかによって異なりますが、不正な形式のHTTPレスポンスを生成しているとは限りません。 –

+0

これは.NET 1.1のサイトであり、不正な形式のHTMLを持っている可能性があります。 – user1231231412

関連する問題