Received: by 10.52.90.36 with SMTP id bt4mr27200228vdb.7.1323249944400;
        Wed, 07 Dec 2011 01:25:44 -0800 (PST)
X-BeenThere: django-developers@googlegroups.com
Received: by 10.52.33.200 with SMTP id t8ls191548vdi.1.gmail; Wed, 07 Dec 2011
 01:25:34 -0800 (PST)
Received: by 10.52.23.70 with SMTP id k6mr27266315vdf.1.1323249934246;
        Wed, 07 Dec 2011 01:25:34 -0800 (PST)
Received: by 10.52.23.70 with SMTP id k6mr27266314vdf.1.1323249934238;
        Wed, 07 Dec 2011 01:25:34 -0800 (PST)
Return-Path: <f.apollo...@gmail.com>
Received: from mail-vw0-f58.google.com (mail-vw0-f58.google.com [209.85.212.58])
        by gmr-mx.google.com with ESMTPS id en7si369121vdb.1.2011.12.07.01.25.34
        (version=TLSv1/SSLv3 cipher=OTHER);
        Wed, 07 Dec 2011 01:25:34 -0800 (PST)
Received-SPF: pass (google.com: domain of f.apollo...@gmail.com designates 209.85.212.58 as permitted sender) client-ip=209.85.212.58;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of f.apollo...@gmail.com designates 209.85.212.58 as permitted sender) smtp.mail=f.apollo...@gmail.com
Received: by vbbfc26 with SMTP id fc26so278658vbb.23
        for <django-developers@googlegroups.com>; Wed, 07 Dec 2011 01:25:34 -0800 (PST)
Received: by 10.52.94.227 with SMTP id df3mr3465693vdb.7.1323249934187;
        Wed, 07 Dec 2011 01:25:34 -0800 (PST)
Date: Wed, 7 Dec 2011 01:25:33 -0800 (PST)
From: Florian Apolloner <f.apollo...@gmail.com>
Reply-To: django-developers@googlegroups.com
To: django-developers@googlegroups.com
Message-ID: <19232315.78.1323249933899.JavaMail.geo-discussion-forums@vbjs5>
In-Reply-To: <bbd6ed3f-3531-4807-b5a6-8ac01b78deab@cs7g2000vbb.googlegroups.com>
References: <7e0a0698-f724-47e3-b39e-1c336b3eb05c@g7g2000vbd.googlegroups.com> <4ED7E65D.8080007@oddbird.net>
 <bbd6ed3f-3531-4807-b5a6-8ac01b78deab@cs7g2000vbb.googlegroups.com>
Subject: Re: PUT and post data
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_76_2797496.1323249933897"

------=_Part_76_2797496.1323249933897
Content-Type: multipart/alternative; 
	boundary="----=_Part_77_7757374.1323249933897"

------=_Part_77_7757374.1323249933897
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,

On Wednesday, December 7, 2011 9:33:52 AM UTC+1, Thibault Jouannic wrote:

> So, don't you think the `request.POST` variable should be processed
> for every request with the "x-www-form-urlencoded" content type,
> whatever the http verb is?
>
That would be really odd imo and confusing as hell if you find 
PUT/DELETE/HEAD/OPTIONS/whatever data in request.POST
 

> But in the case of an urlencoded request, why would django
>
> make PUT requests' processing harder, forcing the user to parse the
> querystring by himself (which is not really well documented, as far as
> I know)?
>

put_data = QueryDict(self.raw_post_data, encoding=your_encoding)
not really hard if you ask me.
 

> If there is a valid explanation, I would be happy to hear it.
> Otherwise, I could provide a patch to solve the issue. Let me know.
>
Stuffing it into POST is a no go, adding an extra PUT/OPTIONS/<whatever 
http verb allows entitity body> is something we don't like either. Given 
that the fix in Client code is a oneliner I think it's not really an issue.

Cheers,
Florian 

------=_Part_77_7757374.1323249933897
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,<br><br>On Wednesday, December 7, 2011 9:33:52 AM UTC+1, Thibault Jouann=
ic wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p>So, don't you =
think the `request.POST` variable should be processed<br>for every request =
with the "x-www-form-urlencoded" content type,<br>whatever the http verb is=
?</p></blockquote><div>That would be really odd imo and confusing as hell i=
f you find PUT/DELETE/HEAD/OPTIONS/whatever data in request.POST<br>&nbsp;<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; =
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">But in the c=
ase of an urlencoded request, why would django<br><p>make PUT requests' pro=
cessing harder, forcing the user to parse the<br>querystring by himself (wh=
ich is not really well documented, as far as<br>I know)?</p></blockquote><d=
iv><br>put_data =3D QueryDict(self.raw_post_data, encoding=3Dyour_encoding)=
<br>not really hard if you ask me.<br>&nbsp;<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb=
(204, 204, 204); padding-left: 1ex;"><p>If there is a valid explanation, I =
would be happy to hear it.<br>Otherwise, I could provide a patch to solve t=
he issue. Let me know.</p></blockquote><div>Stuffing it into POST is a no g=
o, adding an extra PUT/OPTIONS/&lt;whatever http verb allows entitity body&=
gt; is something we don't like either. Given that the fix in Client code is=
 a oneliner I think it's not really an issue.<br><br>Cheers,<br>Florian <br=
></div>
------=_Part_77_7757374.1323249933897--

------=_Part_76_2797496.1323249933897--