id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
34775	A case for handling aditional http methods	João Rodriguez	nobody	"Foreword:

I've done some research on django code and past tickets. It appears this was talked about in length more than 10 years ago. I will include some relevant links in the end but the assumed consensus was that, [https://code.djangoproject.com/ticket/12635#comment:11 as stated by Carl Meyer, 12 years ago]:

   This special case makes sense for POST, since browsers submit HTML forms using those content types. But browsers do not PUT (and ​aren't likely to start), and web services are just as likely (or more likely) to use other content types (e.g. JSON, XML), so it doesn't make sense to special-case form-urlencoded for verbs that aren't used by browsers to submit forms. request.raw_post_data (an unfortunate name, since it's just the request body content, not POST-specific at all) can be accessed directly and parsed as appropriate for the application, according to the content type.

As frameworks and tools evolve, it appears to me that this discussion is worthy to be had again. As it stands, HTMX allows for a broader range of HTTP methods and is gaining traction in the Django community. They also have a standard encoding of `application/x-www-form-urlencoded` with the option to enable `multipart/form-data`. Which fits in very well with existing django code.

This is more of a discussion post but, for the sake of being proactive, here is a, possibly naive, proposed solution. If you are familiar with http RFC, do pitch in!

It does not make sense to me that the methods themselves are blocked when what is not supported by the standard framework are not the methods, but rather aditional encoding forms. Here is the relevant excerpt, with comments by me.

in `django.http.request:354`

{{{
#!python
    def _load_post_and_files(self):
        # the initial if could be removed, as it silently discards any method for custom handling by the user
        # django looks perfectly capable of handling multipart and urlencoded content-types for all methods that have a body
        if self.method != ""POST"":
            self._post, self._files = (
                QueryDict(encoding=self._encoding),
                MultiValueDict(),
            )
            return
        if self._read_started and not hasattr(self, ""_body""):
            self._mark_post_parse_error()
            return

        if self.content_type == ""multipart/form-data"":
            if hasattr(self, ""_body""):
                data = BytesIO(self._body)
            else:
                data = self
            try:
                self._post, self._files = self.parse_file_upload(self.META, data)
            except (MultiPartParserError, TooManyFilesSent):
                self._mark_post_parse_error()
                raise
        elif self.content_type == ""application/x-www-form-urlencoded"":
            self._post, self._files = (
                QueryDict(self.body, encoding=self._encoding),
                MultiValueDict(),
            )
       # silently discards other forms of encoding for custom handling by the user
        else:
           # perhaps allow for the user to attach their own parsing interface for encoding types of their choosing?
           # if the encoding is unsupported by django and the interfaces, why not raise an exception?
            self._post, self._files = (
                QueryDict(encoding=self._encoding),
                MultiValueDict(),
            )
}}}

{{{

}}}

Here are some links on past discussion on the same topic:

https://code.djangoproject.com/ticket/12635#comment:11
https://groups.google.com/g/django-users/c/BeBKj_6qNsc?hl=en
"	New feature	closed	HTTP handling	4.2	Normal	wontfix	HTTP methods, content_type		Unreviewed	0	0	0	0	0	0