Re: #18659 -- Deprecating request.REQUEST

2013-10-18 Thread Marc Tamlyn
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 On 18 Oct 2013 14:55, "Tom

Re: #18659 -- Deprecating request.REQUEST

2013-10-18 Thread Tom Christie
> 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

Re: #18659 -- Deprecating request.REQUEST

2013-10-18 Thread François Schiettecatte
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

Re: #18659 -- Deprecating request.REQUEST

2013-10-18 Thread James Aylett
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

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Shai Berger
On Wednesday 16 October 2013 19:48:09 Aymeric Augustin wrote: > 2013/10/16 Javier Guerra Giraldez > > > 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.

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Aymeric Augustin
2013/10/16 Javier Guerra Giraldez > 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.

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Tom Christie
+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

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Javier Guerra Giraldez
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

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Tim Chase
On 2013-10-16 11:10, Javier Guerra Giraldez wrote: > On Wed, Oct 16, 2013 at 10:14 AM, Shai Berger > 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

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Javier Guerra Giraldez
On Wed, Oct 16, 2013 at 10:14 AM, Shai Berger 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

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Alex Gaynor
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 On Wed, Oct 16, 2013 at 8:14 AM, Shai Berger

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Shai Berger
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

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread John Paulett
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

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Marc Tamlyn
+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 On

#18659 -- Deprecating request.REQUEST

2013-10-16 Thread Tim Graham
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