万恶之源——亚马逊

[pinews]

有气无力了，看我之前如何吐槽 UCloud 的，应该说都是亚马逊开的坏头吧，但是好歹 UCloud 没封住正确的路呀。

https://v2ex.com/t/622536

[eason1874]

你这 18 天前的帖子第一个回复居然是我，但你无视了我的评论。

别万恶了，你在原帖里说的东西基本上都是你自己脑补出来的。

原帖回复其他人说在发送请求方面 PUT 跟 POST 没区别，是对的。rfc2616 明确指出 PUT 和 POST 的本质区别是对 Request-URI 的含义不同，PUT 假设用户知道 Request-URI 代表什么，要求服务器必须把资源存储在 Request-URI 位置，如果没有就创建并返回 201，如果有就更新并返回 200 或 204，如果要应用在跟 Request-URI 不同的位置上必须返回 301 由用户决定要不要改变。POST 没有这种要求，服务器可以自己决定处理 Request-URI 这个位置的资源还是其他资源。

你说的什么 POST 适合小文件传输，PUT 适合大文件传输，没有这回事。什么 cURL 的 POST 和 PUT 对文件要求不一样，也没这回事。

POST 和 PUT 都能用 application/x-www-form-urlencoded （这是你说的用&分割）和 multipart/form-data （这是你说的一个内容）两种数据格式，前者适合简单的文本数据，后者适合大量数据和二进制数据（比如文件）。理论上所有 Content-type 都用，只要服务端支持。

无论是什么 Content-type 的内容都可以读到内存里再提交，或者指定文件流提交，这纯粹是客户端实现，你爱怎么实现怎么实现，cURL 两种方式都支持，并不会区别对待。

[pinews]

我无视你，是不想靠臆测和歪曲观点的人无聊抬杠。

客户端和服务器端交互，你不用 http 也可以，如果这样是不是什么说什么都没意义？现在不就是服务器端和客户端都围绕这客户端代理 curl 转？

你说这说那，有什么根据吗？ curl 对 put 和 post 的要求不同，这是事实，因为你根据自己的观点然后用优越感随便臆测，
rfc2616 的确所了 put 的用途，但是亚马逊表面遵从 put 的用法，实际上却是背弃 put 的用法，本来就是投机取巧的办法，结果到了你这里，显示承认 put 和 post 的区别，转眼就是毫无区别。

因为 put 和 post，所以客户端合理的安排，这是自然而然的事情，但你无视客户端的要求，自己代入客户端说却说怎么用都没问题，

只所以亚马逊投机取巧没出现问题，是因为亚马逊在服务端也相应做了投机取巧才没有产生问题，而不是怎样都可以，也不纯粹是客户端实现。

因为上次发帖有很多不严谨的地方，我在此在此重申，put 和 post 在不同的应用场景使用方法不同，但是也有明确的限制。在传统表单不支持 put 操作。而 post 操作应该将键和值作为内容，让服务器使用，而 put 操作键已经在 url 中体现，内容只要值即可。所以在客户端和服务端改变默认规则是不专业的表现。

请你在拿出些证据再来说，你对 curl 在 put 和 post 的论述上，抱歉，我只能认定你在信口开河。

[eason1874]

@pinews #2 你是婴儿吗，非要我把饭喂到你嘴边你才会吃吗，我已经把你所涉及的知识点分别是什么都说清楚了，你就不会自己动手查一下文档写个测试吗？

另外我再补充一点，你原帖里说 ucloud 对象存储 PHP SDK 单文件上传，说“api 说了 HTTP 方法是 put，但 phpsdk 用的 postfields，这不是 post 吗？”，这也是你脑补出来的。

官方 SDK 写的就是 PUT，我当时测试过这个 SDK，代码也没有错，实际发出请求也是 PUT。你自己看源码： https://github.com/ufilesdk-dev/ufile-phpsdk/blob/master/v1/ucloud/proxy.php#L30

[eason1874]

我看你就是看有个 CURLOPT_POSTFIELDS 就以为是 POST，实际上 PUT 也是用这个名，因为对客户端发送请求来说 PUT 跟 POST 除了名字其他都一样。

[pinews]

post 方法与 put （ upload ）方法的区别