rest - http获取带有请求的正文

  显示原文与译文双语对照的内容

我正在为我们的应用程序开发一个新的RESTful web service 。

在对某些实体进行访问时,客户端可以请求实体的内容。 如果他们想添加一些参数( 例如对列表排序),他们可以在查询字符串中添加这些参数。

或者我希望人们能够在请求正文中指定这些参数。 http/1.1 似乎不明确禁止这里操作。 这将允许他们指定更多信息,可以更容易地指定复杂的xml请求。

我的问题:

  • 这是个好主意?
  • HTTP客户端在获取请求中使用请求正文有问题?

http://tools.ietf.org/html/rfc2616

时间:

restclientREST控制台都不支持这个,但是 curl 。

HTTP规范 。xml在第 4.3节中说明

message-body不能包含在请求如果请求的规范方法( 第 5.1.1节) 不允许发送的entity-body请求。

节 5.1.1 将我们重定向到不同方法的分区 9.x 。 它们中没有一个明确禁止包含消息正文。 但是。。

节 5.2 说明

通过检查Request-URI和主机头字段来确定由互联网请求确定的确切资源。

节 9.3则表示

获取方法意味着检索( 以实体的形式) 所识别的任何信息。

这一起显示在处理get请求时,服务器不是要求检查其他Request-URI和主机标头字段。

总之,http规范不阻止你发送message-body得到但有足够的模棱两可,我不会感到惊讶,如果它被所有服务器不支持。

哪个服务器将忽略它? - fijiaaron 30'12 at 21: 27

谷歌例如比忽视它,它将考虑一个错误!

自己试试用一个简单的netcat:


$ netcat www.google.com 80
GET/HTTP/1.1
Host: www.google.com
Content-length: 6

1234

( 1234内容后面是 CR-LF,所以总共是 6字节)

你会得到:


HTTP/1.1 400 Bad Request
Server: GFE/2.0
(....)
Error 400 (Bad Request)
400. That's an error.
Your client has issued a malformed or illegal request. That's all we know.

你也做得到 400坏请求从bing,苹果, 等等 。 AkamaiGhost提供的服务。

所以我不建议在实体实体中使用get获取请求 with 。

RFC 2616,节 4.3,"邮件正文":

服务器应该在任何请求上读取和转发 message-body ;如果请求方法不包含entity-body的定义语义,那么在处理请求时应该忽略 message-body 。

也就是说,服务器应该总是从网络( 检查 Content-Length 或者读取区块正文等) 读取任何提供的请求正文。 同时,代理应该转发他们接收的任何这样的请求正文。 然后,如果RFC为给定方法定义了主体的语义,那么服务器实际上可以使用请求正文生成响应。 但是,如果 RFC 没有为主体定义语义,那么服务器应该忽略它。

这与上面启动的报价相符。

节 9.3,"获取",描述了get方法的语义,并且没有提到请求正文。 因此,服务器应该忽略接收请求上接收的任何请求正文。

...