HttpWebResponse.GetResponse() fiddler 说“响应标头解析失败。 ”

发布于 2024-12-25 12:01:03 字数 1415 浏览 1 评论 0原文

我正在通过 HttpWebRequest/HttpWebResponse 对象向网站发出请求。

我对网站进行了几次成功的调用,但对同一动态页面的所有其他调用都失败了。

在调试器中,我收到“内部服务器错误 500”fiddler 还显示 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 更低级别的对象可供使用,而不是皮塔饼?

编辑:在上面的示例中我没有包含整个十六进制/整个 html 块。
编辑:关闭fiddler我在调试器中得到了这个

编辑:因此,从我所看到的HttpWebResponse对象正在相应地起作用。服务器只是不稳定,有时会返回具有不同 http 状态代码的相同数据。为了快速修复,我只是将每个调用包装在 try/catch 中,并在 catch 块中重新执行完全相同的调用。到目前为止,它工作得很好,并且半证明了这是站点的错误,而不是 HttpWebResponse 对象的错误。

The server committed a protocol violation. Section=ResponseStatusLine

I'm making a request to a website via the HttpWebRequest/HttpWebResponse objects.

I'm making several successful calls to the web site and every other call to the same dynamic page is failing.

In the debugger I'm getting a "Internal server error 500" fiddler also shows a 500 response and contains:

[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

I've removed all the hex and viewed the page and is what I expect to be returned but for some reason the server is reporting a 500 and the HttpWebRequest object throws an exception on this.

I've tried all the other "fixes" for this issue and none work. It might just be malformed data sent from the server but is there a lower level object to use than HttpWebRequest that's not a pita to work with?

EDIT: I didn't include the entire hex/entire html block in the above example.
EDIT: Turning off fiddler I get this in the debugger

EDIT: So, from what I've seen the HttpWebResponse object is acting accordingly. The server is just flaky and sometime returns the same exact data with different http status codes. For a quick fix I just wrapped each call in a try/catch and in the catch block just retying the exact same call. So far it works great and semi-proves that it's the sites fault and not the HttpWebResponse object.

The server committed a protocol violation. Section=ResponseStatusLine

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

酒废 2025-01-01 12:01:03

HTTP 304 响应意味着自上次访问页面以来页面内容没有更改(它们可能使用缓存)。减少访问页面的频率或缓存响应以供遇到这种情况时使用。

编辑

服务器正在发送包含数据的无效 304 响应。这违反了 HTTP 规范,并且 HttpWebResponse/Fiddler 正在有效地将其转换为 500。

编辑

如果您在 app.config 中使用以下设置,您也许可以继续使用 HttpWebRequest/HttpWebResponse

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

An HTTP 304 response means that the page content has not changed since the last time you hit the page (they're likely using caching). Hit the page less often or cache the response for use when this is encountered.

EDIT

The server is sending an invalid 304 response which contains data. This violates the HTTP spec and the HttpWebResponse/Fiddler is validly transforming it into a 500 as such.

EDIT

You may be able to keep using the HttpWebRequest/HttpWebResponse if you use the following setting in your app.config:

<configuration>
    <system.net>
        <settings>
            <httpWebRequest useUnsafeHeaderParsing="true" />
        </settings>
    </system.net>
</configuration> 
心如荒岛 2025-01-01 12:01:03

Hei Jon,

如果没有 Fiddler,结果是一样的吗? (只是在屏幕上打印异常)。有时我会遇到调试器错误行为的问题。

如果服务器返回间歇性错误并且您无法控制它,恐怕您无能为力。该消息似乎很清楚,这是 304 的标准,响应不应该有正文,但服务器可以做任何它想做的事情,所以这几乎是它需要解决的问题。

请参阅 W3C:http://www.w3.org/Protocols/rfc2616/rfc2616- sec10.html

如果客户端执行了条件 GET 请求并且访问是
允许,但文档尚未被修改,服务器应该使用此状态代码进行响应。 304 响应不得包含消息正文,因此始终以标头字段后的第一个空行结束。

关于HttpWebRequest,我从未遇到过任何问题,也从未听说过它无法处理HTTP通信的任何情况。但如果您想自己动手处理数据包,请谷歌一下如何使用套接字构建您自己的 HttpWebRequest。

这个项目可以是一个开始:
http://www.codeproject.com/Articles/13486 /A-使用 C 套接字的简单爬虫

Hei Jon,

Is the same outcome without Fiddler? (just printing the exception on screen). I had trouble sometimes with debuggers misbehavior.

If the server is returning intermittent error and you do not have control over it, I am afraid you can not do much. The message seems clear that is a standard for 304 that the response should not have a body, but the server can do whatever it wants, so it is pretty much its problem to address to.

See W3C: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

If the client has performed a conditional GET request and access is
allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.

Regarding the HttpWebRequest, I never had any problems, and never heard of any cases it can not handle HTTP communication. But if the case is that you want to go nuts and handle the packets yourself, Google how to build your own HttpWebRequest with sockets.

This project could be a start:
http://www.codeproject.com/Articles/13486/A-Simple-Crawler-Using-C-Sockets

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文