#18659 -- Deprecating request.REQUEST

278 views
Skip to first unread message

Tim Graham

unread,
Oct 16, 2013, 7:13:51 AM10/16/13
to django-d...@googlegroups.com
The ticket now has a patch so I wanted to make sure the consensus is to more forward with this. Here's the rationale from the ticket:

request.REQUEST provides indifferent access to request.GET or request.POST (PHP style).

This attribute is a legacy from the pre-1.0 days, when you could access the GET or POST data using dict syntax on the request object. request.REQUEST was introduced in 1.0 to make this operation more explicit, with an easy upgrade path.

It's hardly ever a good design pattern to handle GET and POST identically, and it's our responsibility not to provide tools who are more likely to result in bad code than anything else. So I think it's time to deprecate this attribute.

We could deprecate django.utils.datastructures.MergeDict at the same time — it's a 100-lines long class whose sole purpose is to support request.REQUEST.



Marc Tamlyn

unread,
Oct 16, 2013, 8:04:09 AM10/16/13
to django-d...@googlegroups.com

+1 to deprecating this. In the rare cases where it is useful (mainly 'next' for redirects) it is very easy to work around it not being there - request.GET.get('next', request.POST.get('next')) - so I see no reason for it to always exist.

In most cases I feel its use is not a good idea™…

Marc

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d5946498-942d-4f47-8446-4eebfdf64f7c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

John Paulett

unread,
Oct 16, 2013, 8:52:56 AM10/16/13
to django-d...@googlegroups.com
I'll chime in with a counterpoint.  

request.REQUEST can be helpful in limited cases when the server application simply does not care whether it is receiving data via a GET query string or x-www-form-urlencoded POST and a different clients can choose which form method is appropriate for its use case (e.g. possibly due to query string length restrictions in some browsers). 

I won't claim this approach is ideal, but I have found it useful on occasion.  Also, I acknowledge that a simple replacement could be "REQUEST = request.POST or request.GET".  If request.REQUEST ends up being removed, I would not be upset, but I did want to state that I use it.

John


Shai Berger

unread,
Oct 16, 2013, 11:14:07 AM10/16/13
to django-d...@googlegroups.com
On Wednesday 16 October 2013 15:52:56 John Paulett wrote:
> I'll chime in with a counterpoint.
>
> request.REQUEST can be helpful in limited cases when the server application
> simply does not care whether it is receiving data via a GET query string or
> x-www-form-urlencoded POST and a different clients can choose which form
> method is appropriate for its use case (e.g. possibly due to query
> string length
> restrictions <http://stackoverflow.com/a/812962/82872> in some browsers).
>
> I won't claim this approach is ideal, but I have found it useful on
> occasion. Also, I acknowledge that a simple replacement could be "REQUEST
> = request.POST or request.GET". If request.REQUEST ends up being removed,
> I would not be upset, but I did want to state that I use it.
>
There is a fine point this seems to miss: The current REQUEST isn't equivalent
to "request.POST or request.GET", but is a merge of the two; it supports a
login form posted to a url like https://example.com/login/?next=eg which your
suggestion wouldn't deal with well.

However, it does so by blurring the distinction between GET and POST
parameters, which like other people here, I find disturbing.

Shai.

Alex Gaynor

unread,
Oct 16, 2013, 11:15:41 AM10/16/13
to django-d...@googlegroups.com
Another +1 for removing it, it makes it way too easy to do something unfortunate, and it's behavior is only really intuitive if you come from PHP, otherwise my first question is, "Where does it look first!?!" every time I see it used.

Alex


--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.




--
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

Javier Guerra Giraldez

unread,
Oct 16, 2013, 12:10:37 PM10/16/13
to django-d...@googlegroups.com
On Wed, Oct 16, 2013 at 10:14 AM, Shai Berger <sh...@platonix.com> wrote:
> However, it does so by blurring the distinction between GET and POST
> parameters, which like other people here, I find disturbing.


care to elaborate about that distinction? both are user-provided
parameters included in the request. the only difference i see is
about encoding.

--
Javier

Tim Chase

unread,
Oct 16, 2013, 12:29:49 PM10/16/13
to django-d...@googlegroups.com, jav...@guerrag.com
Because they're sent different ways. POST variables in the request
body, and GET parameters are in the URL. But it's possible that a
parameter is provided via *both*, and (as Alex notes) the first
question in such a case is "where does it look first?"

I'm +1 on the eventual removal, possibly with a footnoted function
that lets you request the fallback easily if needed. It's a
one-liner as Marc details:

request.GET.get(key, request.POST.get(key))

or

request.POST.get(key, request.GET.get(key))

depending on the priority you want.

-tkc





Javier Guerra Giraldez

unread,
Oct 16, 2013, 12:38:02 PM10/16/13
to Tim Chase, django-d...@googlegroups.com
disclaimer: i'm in no way opposing the deprecation of request.REQUEST.
still, i feel there are lots of bad reasons in PHP-land about
discouraging use of that feature (typically some imagined security
reasons). I'd like to see some good reasons besides aesthetics (yes,
it's ugly) and duplication of functionality.


On Wed, Oct 16, 2013 at 11:29 AM, Tim Chase
<django...@tim.thechases.com> wrote:
> On 2013-10-16 11:10, Javier Guerra Giraldez wrote:
>> On Wed, Oct 16, 2013 at 10:14 AM, Shai Berger <sh...@platonix.com>
>> wrote:
>> > However, it does so by blurring the distinction between GET and
>> > POST parameters, which like other people here, I find
>> > disturbing.
>>
>> care to elaborate about that distinction? both are user-provided
>> parameters included in the request. the only difference i see is
>> about encoding.
>
> Because they're sent different ways. POST variables in the request
> body, and GET parameters are in the URL.


same origin: the browser or any http client

same destination: the web app

same transport: the http request

encoded in different parts of the request (body vs url).

yes, they're different, but is there any value in emphasizing the difference?


--
Javier

Tom Christie

unread,
Oct 16, 2013, 12:46:35 PM10/16/13
to django-d...@googlegroups.com
+1 on removing it.
It's usage reinforces incorrect assumptions about the meaning and behaviour of `request.POST` and `request.GET`.

> It's hardly ever a good design pattern to handle GET and POST identically

I'd phrase is as "It's hardly ever a good design pattern to handle query parameters and request bodies identically", but otherwise exactly this, yes.

Aymeric Augustin

unread,
Oct 16, 2013, 12:48:09 PM10/16/13
to django-d...@googlegroups.com, Tim Chase
2013/10/16 Javier Guerra Giraldez <jav...@guerrag.com>

yes, they're different, but is there any value in emphasizing the difference?

The main value lies in emphasizing the difference between HTTP GET and HTTP POST. That difference has security implications, especially with regards to CSRF.

While pour point is technically valid as far as request.GET and request.POST are concerned, in practice they're so commonly used as a metonymy for HTTP GET and HTTP POST that it's worth having a strong stance on keeping them separate.

-- 
Aymeric.

Shai Berger

unread,
Oct 16, 2013, 12:55:32 PM10/16/13
to django-d...@googlegroups.com, Aymeric Augustin, Tim Chase
On Wednesday 16 October 2013 19:48:09 Aymeric Augustin wrote:
> 2013/10/16 Javier Guerra Giraldez <jav...@guerrag.com>
>
> > yes, they're different, but is there any value in emphasizing the
> > difference?
>
> The main value lies in emphasizing the difference between HTTP GET and HTTP
> POST. That difference has security implications, especially with regards to
> CSRF.
>
Also, GET is supposed to be a "read only" operation.

http://thedailywtf.com/Articles/The_Spider_of_Doom.aspx

James Aylett

unread,
Oct 18, 2013, 9:13:48 AM10/18/13
to django-d...@googlegroups.com
On Wednesday, October 16, 2013 5:48:09 PM UTC+1, Aymeric Augustin wrote:
 
While pour point is technically valid as far as request.GET and request.POST are concerned, in practice they're so commonly used as a metonymy for HTTP GET and HTTP POST that it's worth having a strong stance on keeping them separate.

I'm not entirely serious, but perhaps we should provide better names for `request.GET` and `request.POST` at the same time (with compat). One contains some parameters from the request URL (but can be provided on any HTTP verb, not just GET), the other contains data from the request entity, providing it comes in one of two convenient formats that have common usage (and can be provided on various HTTP verbs, not constrained to POST). The current names are misleading if you try to learn HTTP by learning Django (and I'm guessing a lot of people do).

Certainly the ?next / next= case pointed out above by Marc (a pattern I use a fair amount) would read more precisely (in the absence of `request.REQUEST`, which is a clunky, blurry, quite possibly misguiding but technically no worse named convenience).

I'm +1 on deprecating `request.REQUEST`, and maybe +0 on the rest of what I've just said ;-)

J

François Schiettecatte

unread,
Oct 18, 2013, 9:49:15 AM10/18/13
to django-d...@googlegroups.com
Hi

Just wanted to pitch in as a user of django. I have used request.REQUEST before for a very specific need but I would +1 for it to go.

The question I would have though is for PUT and DELETE methods, would the parameters just wind up in request.POST? Maybe this suggests that renaming request.GET and request.POST to something else might not be a bad idea.

François
> --
> 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-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9cc2400e-6a67-49cd-b5ea-6a03f4618482%40googlegroups.com.

Tom Christie

unread,
Oct 18, 2013, 9:55:10 AM10/18/13
to django-d...@googlegroups.com
> but perhaps we should provide better names for `request.GET` and `request.POST` at the same time

Sure, I'd absolutely agree in principle, and for what it's worth REST framework provides `.QUERY_PARAMS` and `.DATA` attributes on the request which are recommended instead of using `.GET` and `.POST`.  Of course the .DATA attribute in that case provides general purpose request parsing, and isn't limited to form content types.

The current names are fundamentally incorrect, and I think they help sow the seeds for newcomers to misunderstand the basics of HTTP as a result.

Having said that, in practice I don't know if they're something we'd ever move away from.

I don't really feel in any position to judge how we weigh up the current naming awkwardness versus the pain of introducing such a major API difference. 

Marc Tamlyn

unread,
Oct 18, 2013, 2:10:03 PM10/18/13
to django-d...@googlegroups.com

Seems to me an intermediary step is to add request.DATA (then maybe request.QUERY eventually) as a long term movement towards being better http. It isn't something we should do overnight.

I noticed this patch is now in 1.7 and 1.9 will remove request.REQUEST.

Marc

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
Reply all
Reply to author
Forward
0 new messages