为什么Django的HTTPResponseRedirect对PUT使用相同的HTTP方法但不使用POST？

Question

我有一个Django项目,我正在使用视图来处理不同的HTTP方法.该POST处理的对象的创建,然后重定向到同一个视图作为GET(或因此我认为),使用Django的redirect()快捷方式(HTTPResponseRedirect)返回新创建的对象.这很好.我尝试了同样的事情,PUT但我陷入了重定向循环.在我挠了一会儿后,我偶然发现了这个SO答案,然后我推断,由于重定向不处理POST数据,请求变成了一个GET.

当我从以下位置进行重定向时,我通过观察日志来确认这一点POST:

[15/Dec/2014 00:47:43] "POST /client/151/ HTTP/1.1" 302 0
[15/Dec/2014 00:47:43] "GET /client/151/ HTTP/1.1" 200 395

然而,PUT停留a PUT并将我引入重定向循环,直到它出错.

[14/Dec/2014 23:07:36] "PUT /api/asset/6779 HTTP/1.1" 301 0
[14/Dec/2014 23:07:37] "PUT /api/asset/6779/ HTTP/1.1" 302 0
[14/Dec/2014 23:07:37] "PUT /api/asset/6779 HTTP/1.1" 301 0
[14/Dec/2014 23:07:38] "PUT /api/asset/6779/ HTTP/1.1" 302 0
[14/Dec/2014 23:07:38] "PUT /api/asset/6779 HTTP/1.1" 301 0
[14/Dec/2014 23:07:39] "PUT /api/asset/6779/ HTTP/1.1" 302 0
[14/Dec/2014 23:07:39] "PUT /api/asset/6779 HTTP/1.1" 301 0
[14/Dec/2014 23:07:40] "PUT /api/asset/6779/ HTTP/1.1" 302 0
[14/Dec/2014 23:07:40] "PUT /api/asset/6779 HTTP/1.1" 301 0
[14/Dec/2014 23:07:41] "PUT /api/asset/6779/ HTTP/1.1" 302 0
[14/Dec/2014 23:07:41] "PUT /api/asset/6779 HTTP/1.1" 301 0
[14/Dec/2014 23:07:42] "PUT /api/asset/6779/ HTTP/1.1" 302 0

不应该重定向使用GET？我明白发生了什么,但不确定为什么？是什么赋予了？

编辑

# urls.py
url(r'^$', views.put_vs_post_redirect),

# views.py
from django.shortcuts import redirect

def put_vs_post_redirect(request, asset_id):

    if request.method == 'GET':
        return HTTPResponse('Get request')     
    elif request.method == 'POST':
        return redirect('/')
    elif request.method == 'PUT':
        return redirect('/')

Answer 1

正如评论中所提到的,这完全取决于客户端,并非所有客户端都以相同的方式处理重定向.您可以找到重定向代码的合理解释以及为什么301应该在Stack Overflow上丢弃POST数据.

使用301(通常是302)重定向时,大多数浏览器会丢弃POST数据并发出GET请求.这主要是因为浏览器总是这样做,并且POST请求最常来自Web表单,因此重定向导致a有意义GET,允许浏览器显示不同的页面而不会干扰.对于类似PUT或PATCH请求之类的情况并非如此,因为它们目前无法通过Web表单发送,并且通常由不同的规则播放.

如果您希望POST在302重定向上维护数据,则应考虑使用307重定向.甲307请求应保持请求的方法,以及请求主体作为一个结果.

如果您希望POST在301重定向中维护数据,那么目前有一个308状态代码的草稿可以像这样工作307,但是永久性的.

您可以强制重定向到使用GET与请求一个303重定向.它非常像a 302,但它强制请求方法始终是一个GET请求.它经常在API中用于异步任务.