Proposal: Support for HTTP PATCH method

174 views
Skip to first unread message

Krzysztof Jurewicz

unread,
May 20, 2013, 7:48:28 AM5/20/13
to django-d...@googlegroups.com
There is a RFC describing HTTP method named PATCH:

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

Quoting that RFC:
“ The difference between the PUT and PATCH requests is reflected in the
way the server processes the enclosed entity to modify the resource
identified by the Request-URI. In a PUT request, the enclosed entity
is considered to be a modified version of the resource stored on the
origin server, and the client is requesting that the stored version
be replaced. With PATCH, however, the enclosed entity contains a set
of instructions describing how a resource currently residing on the
origin server should be modified to produce a new version.”

Django currently has (seemingly shallow) support for PUT method. Based
on that, I’ve grepped for places in code where it is implemented to see
if support for PATCH could be easily added on a basis of symmetry. Those
places are:

In test client:
There is a `put` method, but `patch` is also implemented:
https://github.com/django/django/commit/293f7a21147ad94c92c7d5b3f33cbab2f87b001b

In View class:
https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/base.py#L33
`put` is listed in http_method_names

In RedirectView:
`put` is a fallback to .get():
https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/base.py#L207

In ProcessFormView:
https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/edit.py#L164
PUT is implemented as a fallback to POST and it seems to assume that
request data is form encoded. While it is not generally true for PUT
method, it looks like a reasonable assumption when processing a form.
However since PATCH request doesn’t have to contain full form data, I
think the best approach may be to not implement `patch` method here
(unless we want to deal with editing only some of the form’s fields –
for example this is the case in Rails, where PATCH will be the primary
method for updates in 4.0 version:
http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-the-new-primary-http-method-for-updates/
). The same stays true to `get_form_kwargs` method in FormMixin:
https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/edit.py#L44
In general, Django’s approach to whether PUT should be treated as a
request containing form data seems to be inconsistent because we
generate forms in the views, but we refuse to generate PUT QueryDict on
a request object:
https://groups.google.com/d/msg/django-developers/dxI4qVzrBY4/m_9IiNk_p7UJ
. So maybe it’s worth to consider removing PUT support in form
processing just on the basis of consistency.

In conclusion, it seems pretty easy to add basic PATCH support similar
to PUT. So if it gets enough +1s, I’m willing to make a patch and hope
it gets included in 1.6 alpha. Or maybe it is (from a technical point of
view) so small a feature that it doesn‘t need to be merged before alpha
release?
--
Krzysiek

Andrey Antukh

unread,
May 20, 2013, 10:46:34 AM5/20/13
to django-d...@googlegroups.com
+1 Many times I had to add this method to the test client.


2013/5/20 Krzysztof Jurewicz <krzysztof...@gmail.com>

--
Krzysiek

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.





--
Andrey Antukh - Андрей Антух - <ni...@niwi.be>
http://www.niwi.be/about.html
http://www.kaleidos.net/A5694F/

"Linux is for people who hate Windows, BSD is for people who love UNIX"
"Social Engineer -> Because there is no patch for human stupidity"

Russell Keith-Magee

unread,
May 21, 2013, 8:38:15 AM5/21/13
to django-d...@googlegroups.com
Hi Krzysztof

These are all reasonable and fairly small I'd be happy to see these added after the alpha - a ticket and patch would definitely be welcome.

The only one that is even remotely controversial to me is the handling of PATCH in ProcessFormView. I agree that there are potential problems with using PUT as an analog of POST, but it largely works in this situation; so I don't know if it's worth deprecating the PUT->POST fallback in this case. 

Strictly, I think it's actually a separate issue -- the first three points you raise are about allowing PATCH at all; the last point is about how we should deal with PATCH in a specific case. Once the first two items on your list are addressed, it would be possible to implement a patch() method on your own generic view subclass; the question is what Django should be doing as a project to make that implementation easier/more useful.

Yours,
Russ Magee %-)

Tom Christie

unread,
May 21, 2013, 12:43:18 PM5/21/13
to django-d...@googlegroups.com
I'm basically in agreement with Russ here.

I'd consider the first three points as being non-controversial.

With regards to ProcessFormView I think implementing a put() method, but not a patch() method falls squarely into the 'good-enough' category of behavior.  In any case, although there are existing conventions, the exact semantics of PATCH requests are a little vague[*], and the generic view's handling of PUT/PATCH is of fairly limited use, given that they only support form-encoded data, and not, say JSON data. Given that, I don't think we need to get too hung up on correctness in that particular area.

Cheers,

  Tom

[*]: As an example Ember's `json-api` style uses RFC 6902, which is more involved than most conventional implementations of PATCH: http://tools.ietf.org/html/rfc6902

Krzysztof Jurewicz

unread,
May 22, 2013, 9:46:45 AM5/22/13
to django-d...@googlegroups.com
W dniu 21.05.2013 14:38, Russell Keith-Magee pisze:
> These are all reasonable and fairly small I'd be happy to see these
> added after the alpha - a ticket and patch would definitely be welcome.

I�ve created a ticket and a pull request with PATCH support for View and
RedirectView (support for test client is already done):

https://code.djangoproject.com/ticket/20478
https://github.com/django/django/pull/1198

I agree that leaving the rest of PUT/PATCH issues untouched for now
looks like a reasonable approach.
--
Krzysiek

Russell Keith-Magee

unread,
May 22, 2013, 8:20:15 PM5/22/13
to django-d...@googlegroups.com
Hi Krzysztof,

Thanks for that patch -- I've just merged it to trunk.

Yours,
Russ Magee %-)

On Wed, May 22, 2013 at 9:46 PM, Krzysztof Jurewicz <krzysztof...@gmail.com> wrote:
W dniu 21.05.2013 14:38, Russell Keith-Magee pisze:

These are all reasonable and fairly small I'd be happy to see these
added after the alpha - a ticket and patch would definitely be welcome.

I’ve created a ticket and a pull request with PATCH support for View and RedirectView (support for test client is already done):


https://code.djangoproject.com/ticket/20478
https://github.com/django/django/pull/1198

I agree that leaving the rest of PUT/PATCH issues untouched for now looks like a reasonable approach.

--
Krzysiek

Reply all
Reply to author
Forward
0 new messages