关于休息：HTTP GET请求正文

HTTP GET with request body

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

在对某些实体执行get操作时，客户机可以请求该实体的内容。如果他们想添加一些参数(例如排序列表)，他们可以在查询字符串中添加这些参数。

或者，我希望人们能够在请求主体中指定这些参数。HTTP/1.1似乎并没有明确禁止这样做。这将允许他们指定更多的信息，可能使指定复杂的XML请求更加容易。

我的问题：

这是个好主意吗？
HTTP客户端在使用GET请求中的请求主体时会有问题吗？

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

相关讨论

将参数放入请求体有什么好处？
其优点是允许轻松发送XML或JSON请求体，它没有长度限制，而且更容易编码(UTF-8)。
如果您所追求的是一个安全的、允许请求主体的等幂方法，那么您可能需要查看搜索、propfind和报告。当然，不使用get和拥有请求主体会或多或少地破坏缓存。
无论规范是否允许，它都违背了休息的精神。
祝客户机实现像搜索这样的请求方法。你更有可能得到+身体。不过，大多数浏览器都不允许这样做(或过去也不允许这样做)。
@费加隆：三年后，从那时起我就有了丰富的网络服务写作经验。这基本上就是我过去几年所做的一切。我可以放心地说，在GET请求中添加主体确实是一个非常糟糕的主意。前两个答案站得像块石头。
我同意。如果您控制从客户机到服务器的所有内容，就可以做到这一点(但是为什么您需要一个WebService)。但如果这是某人想要的，他们可以做到，而不是说不能做的事情，我们可以解释这些陷阱。我也遇到过类似的问题，我想到的最好的答案就是使用Post，不要告诉罗伊·菲尔丁，因为这会让他哭。
@费加隆：我不能替他说话，但我怀疑他会认为纯粹的休息是一切的全部。为工作选择合适的工具。不过，他似乎很关心人们滥用"休息"这个词。
@埃弗特：你有没有机会分享一些你面临的挑战的细节，以及在正文中发送内容？我正在编写我的第一个API，我想我正被引导到使用get+body方法。有一些现实世界中遇到的困难和可能的解决方案的例子是很有用的。
@Ellesedil：简单地说：无论使用get over post有什么好处，都是因为HTTP是如何设计的。当您以这种方式违反标准时，这些优势不再存在。因此，只剩下一个原因可以使用get+a请求体而不是post：美学。不要牺牲稳健的设计而非美观。
这个答案通过引用http/1.1规范stackoverflow.com/a/15656853/244128很好地总结了这一点。
强调埃弗特所说的："它没有长度限制"。如果您的get with query参数打破了长度限制(2048)，那么除了将查询字符串信息放入JSON对象(例如，请求主体)之外，还有其他选择。
Cuin in，最近在C++中为IIS8构建了一个本地HTTP模块，我可以说OnReadEntity不在GET请求上进行攻击，只在POST上进行，或者我很难进入GET请求的主体…
@最终你会做什么？将JSON参数编码为base64？
@JulianReschke你能提供搜索等的指针吗？它们似乎不属于HTTP请求方法(至少在维基百科上)
@beldaz-wikipedia是不相关的；参见iana.org/assignments/http-methods/http-methods.xhtml
后来这篇文章把他的思想扩展到一篇有趣的文章中，指出了这个问题。
@beldaz搜索是一种WebDAV方法。请参见RFC533:Web分布式创作和版本控制(WebDAV)搜索
随着gdpr的出现以及URL查询中允许公开(从而记录)的内容的出现，我们必须重写我们的API，以便在请求主体中传递敏感信息，并将更改写入日志。例如，GET http://host/customer?socialsecuritynumber={ssn}变成了POST http://host/customer/lookup，体内的敏感信息被排除在外测井和内测井之外。

罗伊·菲尔丁(RoyFielding)关于将尸体与GET请求一起包含在内的评论。

Yes. In other words, any HTTP request message is allowed to contain
a message body, and thus must parse messages with that in mind.
Server semantics for GET, however, are restricted such that a body,
if any, has no semantic meaning to the request. The requirements
on parsing are separate from the requirements on method semantics.

So, yes, you can send a body with GET, and no, it is never useful
to do so.

This is part of the layered design of HTTP/1.1 that will become
clear again once the spec is partitioned (work in progress).

....Roy

是的，您可以使用get发送请求主体，但它不应该有任何意义。如果您通过在服务器上分析它并根据其内容更改响应来赋予它意义，那么您将忽略HTTP/1.1规范第4.3节中的建议：

[...] if the request method
does not include defined semantics for an entity-body, then the
message-body SHOULD be ignored when handling the request.

以及http/1.1规范第9.3节中get方法的说明：

The GET method means retrieve whatever information ([...]) is identified by the Request-URI.

声明请求主体不是GET请求中资源标识的一部分，而是请求URI。

更新引用为"http/1.1 spec"的rfc2616现在已过时。2014年被RFC7230-7237替代。引号"处理请求时应忽略消息正文"已被删除。它现在只是"请求消息框架独立于方法语义，即使方法没有为消息体定义任何用途"，"第二个引号"get方法意味着检索任何信息…由请求URI标识"已删除。-从评论中

相关讨论

哪个服务器将忽略它？
知道为什么这是"get的服务器语义"的一部分吗？是否存在缓存/代理问题？
缓存/代理是最有可能破坏的两件事，是的。""语义"只是"制造其他组件的人期望其他组件运行的方式"的另一种说法。如果你违反了语义学，你会更容易看到一些事情在人们写一些期望你遵守这些语义学的东西的地方被打破。
当服务器静默地忽略主体或请求的任何部分时，它会让人头疼。或者它应该解析它，或者以某种方式抱怨它。
dmitri，我认为忽视它符合jon postel的建议"在你接受的事情上保持自由"(RFC1122)。
对于复杂的搜索，也许RESTful不是适合您的解决方案。我已经尝试过使用post请求专门开发自己的协议。每个请求都包含一个JSON主体，其中包含顶级指令。我只有一个接受所有请求的URL，然后根据该指令将它们发送给相应的控制器。
Aetherus，可以工作，但是现在你的身体有效载荷中有了路由细节。这是一个客户必须理解的协议。imho你把界面复杂化了，没有任何好处。
ElasticSearch是一个相当重要的产品，它使用GET中的HTTP请求主体。根据他们的手册，HTTP请求是否应该支持主体是未定义的。我个人不喜欢填充一个GET请求主体，但是他们似乎有不同的意见，他们必须知道他们在做什么。relastic.co/guide/en/elasticsearch/guide/current/&hellip；
@来自HTTP/1.1规范的sam:如果请求方法不包括为实体体定义的语义，那么在处理请求时应忽略消息体。GET方法没有为请求主体指定语义，因此服务器应该忽略它们。
@Iwein给出GET请求主体的含义实际上并不违反规范。HTTP/1.1指定服务器应忽略主体，但RFC 2119指定如果有充分的理由可以忽略"应"子句，则允许实现者忽略该子句。相反，如果客户机假定更改get主体不会更改响应，那么它确实违反了规范。
@Emillundberg我想我理解你的论点，虽然很难揭穿，但这一结论与罗伊·菲尔丁的名言相矛盾。我建议编辑使用"不跟踪"而不是"违反"来完全避免讨论。
引用为"http/1.1 spec"的rfc2616现在已过时。2014年被RFC7230-7237替代。引号"处理请求时应忽略消息正文"已被删除。它现在只是"请求消息框架独立于方法语义，即使方法没有为消息体定义任何用途"，"第二个引号"get方法意味着检索任何信息…由请求URI标识"已删除。所以，我建议编辑答案@jarl
@Gordonm唉，显然他们没有。这个答案是正确的，它违反了GET请求的语义，基于请求体中的任何数据返回响应。
我知道这是一条旧线——我偶然发现了它。@Artem Nakonechny在技术上是正确的，但是新的规范说"GET请求消息中的有效负载没有定义的语义；在GET请求上发送有效负载主体可能会导致一些现有的实现拒绝请求。"因此，如果可以避免，这仍然不是一个真正的好主意。
fastcatch是正确的，@artem nakonechny即使在技术上是正确的，您也可以阅读rfc7231说：在get请求上发送有效负载主体可能会导致一些现有的实现拒绝该请求
假设您希望在一次调用中获得实体列表。(1，4，21，…，100027001)。URL和查询字符串的最大长度是2083个字符。您可以在服务器上增加这个值，但客户机可能会强制执行它。那么，您应该如何执行查询呢？简单地说，您可以使用主体中的ID列表来调用get:getbyids(listids)。另外，如果您的url参数的查询字符串由于任何其他原因而过大，该怎么办？您应该将查询字符串放在get调用的主体中。如果您查看OData规范，如果没有一个带有主体的get，就无法完全实现它。
邮递员最近也开始允许进入人体进行测试。

虽然您可以这样做，但在HTTP规范没有明确排除的范围内，我建议您避免这样做，因为人们不希望事情以这种方式工作。HTTP请求链中有许多阶段，虽然它们"大部分"都符合HTTP规范，但唯一能保证的是，它们的行为将与Web浏览器传统使用的行为相同。(我在考虑透明代理、加速器、A/V工具包等。)

这就是稳健性原则背后的精神，大致上是"接受的内容要自由，发送的内容要保守"，您不想在没有充分理由的情况下推进规范的边界。

但是，如果你有一个很好的理由，那就去做吧。

相关讨论

稳健性原则存在缺陷。如果你接受什么是自由的，你会得到垃圾，如果你在收养方面有任何成功，仅仅因为你接受垃圾。这将使您更难开发接口。看看HTML。这就是实际行动中的再稳定原则。
我认为这些协议的成功和广泛采用(和滥用)说明了健壮性原则的价值。
你有没有尝试过解析真正的HTML？自己实现是不可行的，这就是为什么几乎所有人——包括像谷歌(Chrome)和苹果(Safari)这样的大公司——都没有做到这一点，而是依赖于现有的实现(最终他们都依赖于KDE的khtml)。这种重用当然很好，但您是否尝试在.NET应用程序中显示HTML？这是一个噩梦，因为您要么必须嵌入一个非托管的IE(或类似的)组件，它的问题和崩溃，要么使用一个甚至不允许您选择文本的可用(在codeplex上)托管组件。
HTTP规范只"允许"这一点，因为它不是明确禁止的，任何中间服务器(例如代理)都希望在它们转发的请求中保留消息正文部分。也就是说，这仍然不是人们所期望的。存在Put和Post，以便为这些情况提供正确的语义命令。
@abhijeetpatel ajax请求不随get请求一起发送body数据，因为w3c xmlhttprequest规范不允许这样做(这与HTTP规范没有明显的矛盾)。
HTTP规范不仅允许带有GET请求的body数据，而且这也是常见的实践：流行的ElasticSearch引擎的搜索API推荐带有JSON主体中附加的查询的GET请求。作为对不完整HTTP客户机实现的让步，它还允许在这里发布请求。
@克里斯蒂安·彼得希，这是今天的惯例。四年前不是。尽管规范明确允许客户机在请求(第7节)中可选地包括(可能)一个实体，但在RFC2119中定义了may的含义，并且(crappy)代理服务器可以符合规范，同时剥离get请求中的实体，特别是只要它不崩溃，它可以通过转发请求来提供"减少的功能"。ST头，而不是包含的实体。同样，在不同的协议级别之间进行代理时，也有许多关于必须/可以/应该进行哪些版本更改的规则。
@如果您试图发送带有GET请求的正文，.NET框架将抛出异常。
有人可能会说.NET框架实现是不正确的。

如果尝试利用缓存，可能会遇到问题。代理不会在get主体中查看参数是否对响应有影响。

相关讨论

restclient和rest控制台都不支持这一点，但curl支持。

HTTP规范如第4.3节所述

A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests.

对于各种方法，第5.1.1节将我们重定向到第9.x节。它们都没有明确禁止包含消息体。然而。。。

第5.2节说明

The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.

第9.3节说

The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.

这一起表明，在处理GET请求时，服务器不需要检查请求URI和主机头字段之外的任何内容。

总之，HTTP规范并没有阻止您使用GET发送消息体，但是有足够的模糊性，如果不是所有服务器都支持它，我不会感到惊讶。

相关讨论

ElasticSearch接受带有主体的GET请求。甚至似乎这是首选的方式：http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/common options.html _request_body_in_query_string

一些客户机库(如Ruby驱动程序)可以在开发模式下将cry命令记录到stdout，并且它广泛使用这种语法。

相关讨论

您试图实现的目标已经用一种更常见的方法完成了很长一段时间，而这种方法不依赖于使用带有GET的有效负载。

您可以简单地构建特定的搜索中介类型，或者，如果您想更安静，可以使用OpenSearch之类的工具，并将请求发布到指定服务器的URI，比如/search。然后，服务器可以生成搜索结果，或者构建最终的URI并使用303重定向。

这具有遵循传统的prg方法的优点，有助于缓存中介缓存结果等。

也就是说，uri是为任何非ASCII的内容编码的，application/x-www-form-urlencoded和multipart/form数据也是如此。如果您的目的是支持RESTful场景，那么我建议您使用它，而不是创建另一个自定义JSON格式。

相关讨论

Which server will ignore it? – fijiaaron Aug 30 '12 at 21:27

例如，谷歌做的比忽视它更糟糕，它会认为这是一个错误！

用一个简单的netcat自己尝试一下：

1
2
3
4
5
6

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

1234

(1234内容后跟CR-LF，总共6个字节)

你会得到：

1
2
3
4
5
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个来自必应、苹果等的错误请求…由Akamaighost提供服务。

所以我不建议在实体实体中使用GET请求。

相关讨论

你可以发送一个关于身体的GET，或者发送一个帖子，然后放弃不稳定的宗教信仰(这并不坏，5年前只有一个信仰的成员——他的评论链接在上面)。

这两者都不是很好的决定，但是发送一个get主体可能会防止一些客户机和一些服务器出现问题。

在一些RESTish框架中，发布可能会遇到障碍。

JulianReschke在上面建议使用一个非标准的HTTP头，比如"search"，这可能是一个很好的解决方案，只是它不太可能被支持。

列出能够并且不能完成上述每一项的客户机可能是最有效的。

无法通过正文发送GET的客户端(我知道的)：

XMLHttpRequest小提琴手

可以通过正文发送GET的客户端：

大多数浏览器

可以从get中检索主体的服务器和库：

阿帕奇
PHP

从GET中剥离主体的服务器(和代理)：

相关讨论

来自RFC2616，第4.3节，"消息正文"：

A server SHOULD read and forward a message-body on any request; if the
request method does not include defined semantics for an entity-body,
then the message-body SHOULD be ignored when handling the request.

也就是说，服务器应该总是从网络中读取任何提供的请求主体(检查内容长度或读取块体等)。此外，代理应该转发它们接收到的任何此类请求主体。然后，如果RFC为给定方法的主体定义了语义，那么服务器实际上可以使用请求主体来生成响应。但是，如果RFC没有为主体定义语义，那么服务器应该忽略它。

这与上面fielding的引用一致。

第9.3节"get"描述了get方法的语义，没有提到请求体。因此，服务器应该忽略它在GET请求上接收到的任何请求主体。

相关讨论

我把这个问题提交给IETF HTTP工作组。罗伊·菲尔丁(1998年HTTP/1.1文件的作者)的评论是

"... an implementation would be broken to do anything other than to parse and discard that body if received"

RFC 7213(httpbis)声明：

"A payload within a GET request message has no defined semantics;"

现在看来，意图是禁止对GET请求主体的语义含义，这意味着请求主体不能用来影响结果。

如果您在GET中包含body，那么肯定会有一些代理以各种方式破坏您的请求。

总之，不要这样做。

如果您真的想将cachable-json/xml-body发送到Web应用程序，唯一合理的放置数据的地方是使用rfc4648:base 64编码的查询字符串，使用URL和文件名安全字母表进行编码。当然，您可以只对json进行urlencode，并将其放入url参数的值中，但base64给出的结果要小一些。请记住，存在URL大小限制，请参见不同浏览器中URL的最大长度是多少？.

您可能认为base64的padding =字符可能不利于url的param值，但它似乎不适合-请参阅以下讨论：http://mail.python.org/pipermail/python-bugs-list/2007-february/037195.html。但是，不应该将没有参数名称的编码数据放入，因为带填充的编码字符串将被解释为具有空值的参数键。我会用像?_b64=这样的东西。

相关讨论

根据xmlhttpRequest，它是无效的。根据标准：

4.5.6 The send() method

1
client . send([body = null])

Initiates the request. The optional argument provides the request
body. The argument is ignored if request method is GET or HEAD.

Throws an InvalidStateError exception if either state is not
opened or the send() flag is set.

send(body)方法必须运行以下步骤：

如果状态未打开，则引发InvalidStateError异常。

如果设置了send()标志，则抛出InvalidStateError异常。

如果请求方法是Get或HEAD，则将body设置为空。

如果body为空，则转到下一步。

< /块引用>
不过，我不认为应该这样做，因为GET请求可能需要大量的内容。
因此，如果您依赖于浏览器的xmlhttpRequest，它很可能不会工作。

相关讨论

因为xmlhttpRequest是一个实现，所以被否决。它可能不反映它应该实现的实际规范。

上面的downvote是错误的，如果一些实现不支持发送带有get的主体，那么这可能是不执行该操作的原因，不管规范如何。实际上，我在一个我正在工作的跨平台产品中遇到了这个问题——只有使用xmlhttpRequest的平台未能发送GET。

不一致的base64编码头怎么样？"一些thingpp-params:sdfsd45fdg45/as"
长度限制嗯。你不能让你的后处理区分意思吗？如果你想要简单的参数，比如排序，我不明白为什么会有问题。我想你肯定很担心。

相关讨论

您可以使用x-前缀发送任何需要的参数，对头的长度的任何限制都是服务器的任意限制。

例如，它与curl、apache和php一起工作。
PHP文件：

1
2
3
<?php
echo $_SERVER['REQUEST_METHOD'] . PHP_EOL;
echo file_get_contents('php://input') . PHP_EOL;

控制台命令：

1
$ curl -X GET -H"Content-Type: application/json" -d '{"the":"body"}' 'http://localhost/test/get.php'

输出：

1
2
GET
{"the":"body"}

相关讨论

有趣的实验！php只在body与post请求和application/x-www-form-urlencoded一起发送时在$_POST中读取。这意味着在GET请求中忽略了主体。在这种情况下：在这一点上，$_GET和$_POST都是非常误导的。所以最好使用php://input。

imho您只需发送URL中的JSON编码(即encodeURIComponent编码)，这样您就不会违反HTTP规范，并将JSON发送到服务器。

相关讨论

是的，但主要的问题是长度限制，我们如何处理？

我不建议这样做，它违背了标准惯例，并且没有提供那么多回报。您希望保留正文内容，而不是选项。

我很不高兴RESTAS协议不支持OOP，Get方法就是证据。作为一种解决方案，您可以将DTO序列化为JSON，然后创建一个查询字符串。在服务器端，您可以将查询字符串反序列化为DTO。
看一看：

ServiceStack中基于消息的设计

使用WCF构建基于消息的RESTful Web服务

基于消息的方法可以帮助您解决get方法的限制。您可以通过请求正文将任何DTO发送给
Nelibur Web Service Framework提供您可以使用的功能

1
2
3
4
5
6
7
8
9
10
var client = new JsonServiceClient(Settings.Default.ServiceAddress);
var request = new GetClientRequest
{
Id = new Guid("2217239b0e-b35b-4d32-95c7-5db43e2bd573")
};
var response = client.Get<GetClientRequest, ClientResponse>(request);

as you can see, the GetClientRequest was encoded to the following query string

http://localhost/clients/GetWithResponse?type=GetClientRequest&data=%7B%22Id%22:%2217239b0e-b35b-4d32-95c7-5db43e2bd573%22%7D

相关讨论

你应该只用post。如果在URL中有方法名，则会违反基本的REST设计。这是rpc，使用post。

我认为这不是什么大问题，我们在使用RESTful URL(即orders/1)开发过程中遇到了更多的问题。至于我，get方法有问题，它与oop不兼容。谁在乎url是什么样子的：)但是通过基于消息的方法，我们可以创建稳定的远程接口，这非常重要。另外，它不是RPC，它是基于消息的

我觉得你错过了整个休息点。当你说，谁在乎URL是什么样子的时候，好吧，其他人很关心。为什么REST与OOP兼容？

不，我没有。我只是看得更远一点。

您有一个选项列表，比使用带有get的请求主体要好得多。
假设每个类别都有类别和项目。两者都由一个ID标识("catid"/"itemid"用于本例)。您希望根据另一个参数"sortby"按特定的"order"进行排序。要传递"sortby"和"order"的参数：
你可以：

使用查询字符串，例如example.com/category/{catid}/item/{itemid}?sortby=itemname&order=asc

对路径使用mod_rewrite(或类似方法)：example.com/category/{catid}/item/{itemid}/{sortby}/{order}

使用与请求一起传递的单个HTTP头

使用其他方法(例如post)检索资源。

所有这些都有其缺点，但远比使用一个有身体的GET要好得多。