使用Web.py的HTTP POST响应失败 [英] HTTP POST Response Fails Using Web.py

问题描述

我想不言而喻，我对以下内容感到困惑.这是我在此处的查询的虚假延续: HTTP 303(查看其他):GET可行，POST失败我要发布另一个问题，因为其他问题主要涉及HTTP重定向，并且无法解决我现在认为是潜在的问题.

I suppose it goes without saying that I'm baffled by the following. This is a faux-continuation of my queries here: HTTP 303 (SeeOther): GET Works, POST Fails I'm posting another question because the other deals primarily with HTTP redirections, and does not address what I now believe to be the underlying problem.

我有一个非常简单的web.py类:

I have a very simple web.py class:

class user:
        def GET(self, id):
                """List a single user"""
                web.header('Cache-control', 'no-cache')
                return 'wtf!!'

        def POST(self, id):
                """Save an updated user"""
                web.header('Cache-control', 'no-cache')
                return 'wtf!!'

如果我从此资源中获取，我会收到我愚蠢的'wtf !!'.文字作为回应.

If I GET from this resource, I receive my stupid-simple 'wtf!!' text in response.

如果我发布到该资源，则根据请求的来源会得到不同的结果.

If I POST to this resource, I get mixed results depending on the source of the request.

• Google Chrome浏览器:完全失败.使用开发人员工具网络分析器，我可以看到请求发送出去了.大约15秒后，它说失败了.
• IE9 :从技术上讲，它可以正常工作.等待约15秒钟后，预期的响应将始终到达.
• PuTTY/Telnet:完美运行.如预期的那样，该响应几乎立即出现.

• Google Chrome: Completely fails. Using the developer tools network analyzer, I can see the request go out. After ~15 seconds, it says that it failed.
• IE9: Technically, it works. After waiting for ~15 seconds, the expected response will always arrive.
• PuTTY/Telnet: Works perfectly. The response appears near-instantaneously, as expected.

考虑到Web浏览器可能添加了一些破坏web.py的标头，我决定打开Wireshark进行调查.我发现客户总是会及时收到答复.但是，我确实注意到，Wireshark并未将对POST请求的响应识别为HTTP(这是对GET请求的响应所要做的事情).

Thinking that perhaps the web browsers were adding some headers that broke web.py, I decided to open up Wireshark to investigate. I found that the responses were always received by the client in a timely manner. However, I did notice that Wireshark was not recognizing the responses to a POST request as HTTP (which is something it would do for the responses to a GET request).

我一直在对此进行测试/故障排除，并且我还有更多的发展.

I've been working on testing/troubleshooting this and I have more developments.

GET和POST响应都以标头"Transfer-encoding:chunked"返回给客户端.这意味着，而不是发送整个页面，它会在准备就绪时发送零碎的信息.通用格式为:

The GET and POST responses are both coming back to the client with the header 'Transfer-encoding: chunked'. This means that rather than sending the whole page, it will send bits and pieces as they're ready. The general format is:

200 OK, etc
{Headers}

5              # Num. of Chars in This Chunk (in hex)
Hello

200 OK, etc
{Headers}

0              # Signifies no more chunks to come

我使用Wireshark查找这些数据包.我注意到GET响应看起来应该是应该的，但是POST响应似乎缺少最后一块.结果，连接一直保持打开状态直到超时(因为它希望来自服务器的数据更多).

I use Wireshark to look for these packets. I'm noticing that the GET response looks like it should, but the POST response seems to be missing that last chunk. As a result, the connection stays open until it times out (since it expects more data to come from the server).

这里有一些事正在服务器端处理请求.我不确定哪个负责分块"数据.

Here are things that are touching the request on the server side. I'm not sure which one is responsible for 'chunking' the data.

• Apache
• mod_cgi
• 潮气
• web.py
• 我的应用

我现在的问题:

哪个组件实际上分块了"我的请求?

Which component actually 'chunks' my request?

为什么无法发送最后一个块(仅用于POST响应)?

Why is it failing to send the last chunk (only for POST responses)?

推荐答案

我试图复制您的问题.一切都正常工作.

I tried to replicate your problem. And it all is working properly.

班级:

class User:
    def GET(self, id):
        """List a single user"""
        web.header('Cache-control', 'no-cache')
        return 'GET' + str(id)

    def POST(self, id):
        """Save an updated user"""
        web.header('Cache-control', 'no-cache')
        raise web.seeother('/user/2')

对于网址: urls = ( r'/user/?(\d*)', "User", )

And for urls: urls = ( r'/user/?(\d*)', "User", )

当我执行POST(使用FF)时，一切都可以正常工作.

And it all working when I'm doing POST (using FF).

您使用任何中间件吗?

这篇关于使用Web.py的HTTP POST响应失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！