我正在向 google reader api 发送一个 http 请求并得到一个不寻常的响应代码。根据文档，我请求了一个身份验证代码并将其包含在每个请求的标头中。执行登录并获取授权码后，我尝试访问此网址，这是文档的一部分：
http://www.google.com/reader/api/0/stream/items/contents
当我发送请求时，我收到 411 状态代码，这应该是意思是“需要长度”。正如我发现的，长度应该是消息正文的长度（以八位位组为单位）。该请求中没有消息正文。只有一个标头、POST 参数 i="item id" 和 URL 本身。我尝试将“Content-Length”标头设置为“0”，也设置为“-1”，但无济于事。
真正有趣的是，在谷歌更改其授权程序之前，相同的代码运行良好。很明显他们已经改变了其他东西......
所以我的问题是到底什么会导致 411 响应代码以及我该如何防止它？
i'm sending an http request to the google reader api and getting an unusual response code. following the documentation, i've requested an auth code and included it in the header of every request. after performing the login, and getting an auth code, i tried accessing this url, which is part of the documentation:
http://www.google.com/reader/api/0/stream/items/contents
when i send the request, i get a 411 status code, which is supposed to mean "Length Required". the length, as i've found, is supposed to be the length, in octets, of the message body. there is no message body in this request. there is only a single header, the POST parameter i="item id" and the URL itself. i tried setting the "Content-Length" header to "0" and also to "-1" to no avail.
what's really interesting is that this same code worked fine before google changed their authorization procedure. it's apparent they've changed something else...
so my question is what EXACTLY would cause a 411 response code and how can i prevent it?
发布评论
评论（1）
此错误仅发生在 POST 和 PUT 请求类型中，因为这两种（某种程度上）期望有一个包含请求参数（纯文本和附件）的请求正文。
然而，正如文档所示，这在很大程度上是一个过时的值，实际上 Web 服务应该在不依赖 Content-Length 的情况下处理请求。
所以这不是请求发送者的问题，而是（我想说）服务端的错误。
不过，将 Content-Length（注意正确的大小写）请求标头设置为 0 应该是解决方法。
This error happens only with POST and PUT request types, as these two (sort of) expect to have a request body that includes the request parameters (plain textual as well as attachments).
However as the documentation suggests, this is largely an obsolete value, and realistically the web services should handle requests without relying on Content-Length.
So it's not the problem of a request sender, but it is (I would say) a bug on the service side.
Nevertheless, setting a Content-Length (mind the proper capitalisation) request header to 0 should be the workaround.