是否需要HTTP PUT请求包含主体?


91

我在标准中找不到明确的规范时遇到麻烦。我有一个HTTP客户端,它Content-Length: 0在执行PUT请求时没有包括标头,而我没有指定主体,而服务器却被此类请求弄糊涂了,我想知道应该归咎于哪个程序。


如果我要问的话,您为什么还要编辑2009年的问题?
zmuci

@zmuci是否需要更好的格式?
КонстантинВан

Answers:


81

如果HTTP请求具有Content-Length或Transfer-Encoding标头(RFC 2616 4.3),则具有正文。如果请求都没有,则它没有主体,您的服务器应该这样处理。

也就是说,PUT请求没有主体是不寻常的,因此,如果我设计的客户确实想发送一个空主体,我将传递Content-Length:0。确实,这取决于一个人对POST的阅读情况和PUT方法定义(RFC 2616 9.5,9.6)可能会认为隐式要求使用主体-但是处理任何主体的合理方法是采用零长度主体。


正如HTTP状态代码200(“确定”),201(“已创建”)和204(“无内容”)所暗示的,PUT请求基本上是用于在服务器上创建或更新文件。而且没有任何关于文件为空的非法行为,不是吗?
48КонстантинВан


5
@bdonlan,您说带有空主体的PUT是不寻常的,但是如果我要启用或禁用用户,则不需要我的请求中的主体,实际上PUT请求可以是“ / users / {id} / enable”或“ /用户/ {id} /禁用”。
Vinicius de Almeida

@ViniciusdeAlmeida如果您尝试遵守REST标准,那么这些资源将不合适。disableenable是动词。在这种情况下,我可能更愿意PATCH/users/{id}端点上使用。
暗恋

42

没有回答问题,而是断言jaxrs如何使我频繁使用无体PUT:

无主体认沽权的示例:给用户额外的权限。

PUT / admin / users / {用户名} / permission / {permission}


2
正是我的问题!我得出了相同的结论。但是严格来说,这与RFC背道而驰,尽管没有明确提及,但仍将其称为“现有”。它可能会引起问题,但以我的经验,所有现代Web服务器/框架都可以使用。
Agoston Horvath

在类似的情况下,我需要一个API来将现有资源与用户相关联。我可以在主体中使用带有resourceId的POST users /:userId / resources。或更确切地说,它将适合PUT用户/:userid / resources /:resourceId。这里的最大区别是,firt API应该是非幂等的,因此我可以将同一资源两次关联到用户。PUT呼叫应重置先前的关联
Carmine Ingaldi '19

5

IETF标准不要求使用正文,但是如果没有正文,则content-length应该为0。使用适合您正在执行的方法。如果您将其放入代码中,则给出

int x;
int f(){ return x; }

和一个名为的远程变量r

帖子等同于

r=f();

看跌期权等同于

r=x;

得到等于

x=r;

1
这是我读过的PUT与POST的最清楚的例子,尽管没有主题
数字错觉

如果请求具有Content-Length标头,则它具有正文。它可能是一个空的身体,但仍然是一个身体。与没有Content-Length标头的请求相反,该请求根本没有正文,甚至没有一个空正文。因此,是的,严格来讲,PUT请求必须具有主体。总是。
Paul Groke

您的POST类比也让我完全困惑。如果我尝试保持其余的比喻,那应该更像服务器具有一个int f(int* resource, int body);,然后POST将调用它f(&r, x);-r无论服务器认为合适,它都可以做或不做。但是它也可以返回东西,所以……也许更像是y = f(&r, x);
Paul Groke

0

如果没有内容,则将PUT(以动词形式)放在服务器上是什么?该规范是指内容“封装的实体”,但没有内容的请求就没有封闭的实体,因此没有把服务器上。

当然,除非您不希望将任何内容都不放到服务器上,否则这种情况下您可能希望使用DELETE。


1
您的
推入内容

1
PUT空只是声明具有给定标识的资源必须在服务器上存在,尽管它除了标识本身之外没有其他内容。那是与DELETE完全不同的语义。
伊姆雷·普维尔(ImrePühvel)'18年

假设您要放置资源,但是接受所有服务器端默认值。那将是以JSONContent-Length: 0还是{ }以JSON为主体?
路加·普普利特

1
因此,您的计算机上没有单个空文件,对吗?
КонстантинВан

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.