Interaction between getPostParam and file uploads - Snap Framework

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Interaction between getPostParam and file uploads
Received-SPF: neutral (google.com: 209.85.220.173 is neither permitted nor denied by best guess record for domain of g...@gregorycollins.net) client-ip=209.85.220.173;
MIME-Version: 1.0
In-Reply-To: <CAPwAf1=OBsS-nzGmuO7byGebgwgXi=_S_Ws2WazbFyonP+C...@mail.gmail.com>
References: <CAPwAf1=OBsS-nzGmuO7byGebgwgXi=_S_Ws2WazbFyonP+C...@mail.gmail.com>
Date: Sat, 15 Sep 2012 09:01:18 +0200
Message-ID: <CAHZrzdqV7fQCWBqsZUA-CjZwkQ7=qU0JtXRP1eE48V4KR+-...@mail.gmail.com>
Subject: Re: [snap] Interaction between getPostParam and file uploads
From: Gregory Collins <g...@gregorycollins.net>
To: snap_framework@googlegroups.com
Content-Type: multipart/alternative; boundary=20cf307f31fc72473c04c9b81b7d

--20cf307f31fc72473c04c9b81b7d
Content-Type: text/plain; charset=UTF-8

On Fri, Sep 14, 2012 at 5:56 PM, Leon Smith <leon.p.sm...@gmail.com> wrote:

> I've had a problem where getPostParam/getParam returns Nothing for a CSRF
> token passed to Snap as a hidden form parameter when dealing with file
> uploads.   I've included a minimal-ish demonstration of the behavior.
>
> Now, it makes sense that Snap would not find the "comment" field until
> after the file upload is completed,  because the browser sends the comment
> after the file and Snap would have to process the entire file upload before
> it would receive the comment field.   But the browser sends the CSRF token
> before the file upload,   and yet both getPostParam and getParam return
> Nothing,  which seems like a bug.
>

Definitely not a bug here. You're misunderstanding the Snap execution
model. When control is passed to the user handler, unless the request body
has a type of application/x-www-form-encoded, the request body has NOT been
read at all. The reason for this is that the request body can be large and
Snap doesn't know what to do with it -- we're obviously not going to read
it into RAM, and we're also not just going to shunt every request to disk.
This has to be left up to the programmer.

So with a multipart/form-data upload, the parameter you're looking for is
not in the parameters map because you haven't read it from the socket yet!
It will be in the parameters map *after* the handleFileUploads call
finishes. Usually we stuff the csrf token in a cookie for this reason,
although you're going to have to read the whole request body anyways to
maintain the HTTP protocol invariants. If you want the connection to be
forcibly terminated instead, you have to call terminateConnection.

Hope this helps.

G
-- 
Gregory Collins <g...@gregorycollins.net>

--20cf307f31fc72473c04c9b81b7d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Sep 14, 2012 at 5:56 PM, Leon Smith <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:leon.p.sm...@gmail.com" target=3D"_blan=
k">leon.p.sm...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
I&#39;ve had a problem where getPostParam/getParam returns Nothing for a CS=
RF token passed to Snap as a hidden form parameter when dealing with file u=
ploads. =C2=A0 I&#39;ve included a minimal-ish demonstration of the behavio=
r.<div>

<br></div><div><div>Now, it makes sense that Snap would not find the &quot;=
comment&quot; field until after the file upload is completed, =C2=A0because=
 the browser sends the comment after the file and Snap would have to proces=
s the entire file upload before it would receive the comment field. =C2=A0 =
But the browser sends the CSRF token before the file upload, =C2=A0 and yet=
 both getPostParam and getParam return Nothing, =C2=A0which seems like a bu=
g.</div>

<div></div></div></blockquote></div><div><br></div><div>Definitely not a bu=
g here. You&#39;re misunderstanding the Snap execution model. When control =
is passed to the user handler, unless the request body has a type of applic=
ation/x-www-form-encoded, the request body has NOT been read at all. The re=
ason for this is that the request body can be large and Snap doesn&#39;t kn=
ow what to do with it -- we&#39;re obviously not going to read it into RAM,=
 and we&#39;re also not just going to shunt every request to disk. This has=
 to be left up to the programmer.</div>
<div><br></div><div>So with a multipart/form-data upload, the parameter you=
&#39;re looking for is not in the parameters map because you haven&#39;t re=
ad it from the socket yet! It will be in the parameters map *after* the han=
dleFileUploads call finishes. Usually we stuff the csrf token in a cookie f=
or this reason, although you&#39;re going to have to read the whole request=
 body anyways to maintain the HTTP protocol invariants. If you want the con=
nection to be forcibly terminated instead, you have to call terminateConnec=
tion.</div>
<div><br></div><div>Hope this helps.<br><br></div><div>G</div>--=C2=A0<br>G=
regory Collins &lt;<a href=3D"mailto:g...@gregorycollins.net" target=3D"_bl=
ank">g...@gregorycollins.net</a>&gt;<br>

--20cf307f31fc72473c04c9b81b7d--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
